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I. INTRODUCTION 


A. PURPOSE 

Operational and training readiness of Na \7 ships depends on the efilcient manage¬ 
ment of onboard supplies. Food, fuel, and ammunition inventories must be effectively 
monitored and controlled. Higher command authorities have recognized the critical na¬ 
ture of these inventories by mandating reporting procedures to ensure the proper place¬ 
ment of these vital supplies. Clearly, the ability of a warship to go quickly into combat 
is determined largely by the supplies carried in her own hull. 

The vital importance of efficient shipboard inventory management is especially ob¬ 
vious in the area of conventional ammunition inventory, requisitioning, and reporting. 
Ammunition logistics determines a ship's possible endurance and available tactics. In 
peacetime, tracking the expenditure and replacement of shipboard ordnance is especially 
important because of its impact on combat systems training readiness. A ship in which 
operational and tactical decision makers are unaware of the quantity and type of ord¬ 
nance onboard is at a clear disadvantage in peacetime and may prove to be a dangerous 
liability in hostile environments. 

Over the past decade, audits of shipboard ammunition management procedures have 
focused attention on an apparent inability to maintain accurate ammunition records. 
For example, two General Accounting Office (GAO) investigations (GAO, 1981 and 
1982) found significant discrepancies between reported quantities and assets actually 
onboard. The Naval Audit Service discovered a similar finding when it audited small 
arms and ammunition (NAS, 1981). As we face the austere defense funding levels ex¬ 
pected for the 1990's, Nav 7 managers must address the deficiencies inherent in the cur¬ 
rent manual system of shipboard ammunition management. 

The present (entirely manual) system of shipboard ammunition management is 
manpower intensive, inefficient, invites errors, and provides poor information support 
for shipboard managers. The requisitioning, status tracking, expenditure reporting, and 
inventory management of ammunition inventories to comply with detailed requirements 
of higher authority imposes a significant administrative burden on Weapons Department 
personnel. An automated system would relieve part of this administrative burden, mak¬ 
ing time available for important combat systems training. In addition, an automated 
system would make accurate ammunition information more accessible to decision mak- 
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ers both on and off the ship. Unfortunately, automated tools for shipboard ammunition 
management do not exist, either as part of the Shipboard Kon-Tactical ADP (SNAP) 
system installed on Navy ships or as a stand-alone microcomputer application. 

The purpose of this thesis is to provide the analysis and design for a prototype re¬ 
lational database application intended to automate the manual system of shipboard 
ammunition inventory, requisitioning, and reporting. 

B. SCOPE 

1. Scope of System 

This thesis defines the relational database design of the proposed Ammunition 
Requisition Management, Inventory', and Reporting System (ARMIRS), a single-user, 
microcomputer-based database application. The scope of ARMIRS is limited in that (1) 
the current system defines the principal functional requirements of the automated sys¬ 
tem, (2) the special requirements of ammunition stores ships afloat and naval magazines 
ashore are not addressed, and (3) only non-nuclear ordnance management is modeled. 

It is not the intent of this research to specify the ideal methods for shipboard 
ammunition management or to suggest fundamentally different methods of ordnance 
inventory, requisition, or reporting. Rather, ARMIRS is an automated application of a 
manual system, using forms and reports familiar to users of the current system. 

In addition, ARMIRS will not meet the special requirements of non-combatant 
ships. A single ammunition supply ship carries ammunition bound for many combatant 
ships and has especially complex requirements for ammunition load management. 

Finally, ARMIRS is an unclassified system for unclassified ordnance. Nuclear 
weapons management has distinct managerial and security requirements beyond the 
scope of this system. Because of the comparatively small quantity of weapons involved 
and the demanding security requirements, inclusion of special weapons within the scope 
of ARMIRS is not required. 

2. Scope of Thesis 

This thesis will facilitate future development of a prototype ARMIRS system 
by defining the data and functional requirements of the system. The deliverable product 
from this thesis is the documentation of the analysis and design phases of systems de¬ 
velopment. A high-level conceptual data model is described. This conceptual schema is 
a concise description of the user's data requirements and includes detailed descriptions 
of the data types, relationships, and constraints. The functional requirements of a 
shipboard ammunition management system will also be specified. These design specifi- 
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cations are independent of any particular Database Management System (DBMS). The 
specifications from this thesis can then be implemented with a variety of DBMS appli¬ 
cation tools. Data model mapping into the data model of PARADOX,! a relational 
microcomputer DB.MS product with built-in application development facilities, is used 
only to demonstrate the transformation of the conceptual schema from a high-level data 
model to an implementation data model. In addition, PARADOX is used as a graphic 
interface tool to specify the ARMIRS reports. However, a DBMS-specific, working 
prototype is beyond the scope of this thesis. 

C. METHODOLOGY 

This thesis generally follows the object-oriented database design steps outlined by 
Kroenke and Dolan (1988, pp. 87-216) and by Elmasri and Navanthe (1989, pp. 
453-483). In general, these steps include: 

1. Model the user's view of the data as objects. 

2. Specify the application and its functional components as data flows. 

3. Define the relational schema. 

4. Design the control and display features of the application, including forms and re¬ 
ports. 

According to Kroenke and Dolan (1988, pp. 96-97), there are two methods to use 
in identifying and describing objects: (1) examine the application outputs and work 
backwards to the object structure, or (2) ask the user to describe the objects and model 
the objects from their characteristics and the application. The first methodology is useful 
when an improved application for an existing system is required. By knowing the system 
output, it is possible to determine the input. The second method is required for new ap¬ 
plications. Because there are no reports or views to examine, the analysts begin by ask¬ 
ing users to describe their view of the system objects. 

The former methodology is appropriate for ARMIRS. The ARMIRS requirements 
analysis draws from the previous requirements work by Alderman (1986) and Smith 
(1987) as well as the author's own shipboard ammunition management experience.2 In 
addition, interviews with Gunnery' Officers and Gunnery Petty Officers aboard four 

1 PARADOX is trademark of Borland International. 

2 The author served as ASW Officer (13 months) and Weapons Officer (5 months) aboard a 
KNOX-class frigate. 
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combatant ships3 were conducted during July 1989^ to supplement the author's expertise 
and aid in modeling the user's view of the system. 

This thesis incorporates the dataflow diagram methodology of Yourdon (1989) into 
the Kroenke and Dolan framework. The techniques developed by Hayes-Roth (1985) as 
applied by Kamel and Lekey (1990) are used to define a rule-based expert system that 
could be integrated with the ARM IRS database to assist in Ammunition Transaction 
Report (ATR) and requisition preparation. 

The specific tools used and their relationship to the corresponding design steps are 
discussed in the context of thesis organization. This organization closely parallels the 
format used by the author in an unpublished work (Buzzard, et. al, 1989) using the 
Kroenke and Dolan framework. 

D. PREVIOUS WORK 

As previously discussed, this thesis is limited to the analysis and design phase of the 
database application system life cycle. The problem of this phase, as stated by Elmasri 
and Xavanthe (1989, p. 457), is to "design the logical structure of one or more databases 
to accomodate the information needs of the users in an organization for a defined set 
of applications". This thesis does not attempt to rewrite the existing requirements anal¬ 
ysis of Alderman (1986) or the requirements analysis and partial, DBMS-specific design 
by Smith (1987). Instead, this thesis is a continuation of these previous efforts to auto¬ 
mate ammunition management. 

Alderman's (1986) thesis was heavily influenced by the X'avy's Conventional Am¬ 
munition Integrated Management System (CAIMS) database. The data dictionaiv' he 
presents for a shipboard system is copied from the COBOL description of data elements 
in the C.^IMS system. Alderman's (1986, pp. 32-35) file-based system is also outdated 
because it uses separate files (and forms) for sonobouys and for explosive ordnance. 
Sonobouys previously had different reporting and requisitioning requirements. Use of a 
file-based approach created vnnecessar}' complexity, including many condition flags. 
Because Alderman specified custom-made security and backup components in the sys¬ 
tem rather than simply adding commercially available software to accomplish these sys¬ 
tem management functions, additional dataflow diagrams and forms were necessary'. In 
addition, because a query-by-forms model was not used, the review, create, and update 
functions were each accomplished by unique forms. Alderman (1986, p. 106-127) used 

3 USS MCCLUSKEY (FFG-41). USS MARVIN SHIELDS (FF-1066), USS STEIN 
(FF-1065), and USS JOHN YOUNG (DD-973). 
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43 forms to define the system, many of them unnecessarj' for the reasons discussed 
above. The requirements analysis is also incomplete in that important functions are not 
described. For example, the internal reports generated by the system for shipboard use 
are not described or even listed. Alderman, a Supply Corps officer, oriented the re¬ 
quirements analysis toward a Na\T-wide logistics view than from the shipboard user's 
view of the system. 

Smith's (1987) thesis comes closer to defining the user's view of a shipboard am¬ 
munition management system. An analysis of the current manual system receives some 
examination. The major shortcoming in Smith's work is the attempt to begin the imple¬ 
mentation (construction) phase before completing the design phase. The result is a par¬ 
tial, DBASE llH-specific implementation fragment. Smith's (1987, p. 53) chapter on 
"design" begins with a physical structure description of the DBASE III files used. As 
Whitten, ei, at., (1986, p. 158) point out, the design specifications should be fully com¬ 
pleted before the implementation phase begins. We should avoid the temptation to pre¬ 
maturely program from an incomplete design or we risk numerous delays. The Smith 
(1987) thesis is therefore an analysis and implementation approach to the shipboard 
ammunition management problem. There is nothing in that thesis resembling a logic 
description or logic specification (pseudocode) to bridge the gap between analysis and 
Smith's DBASE III code. For this thesis, some reverse engineering was applied to some 
of Smith's (1987, pp. 137-177) DBASE code to provide another user's view. Smith (1987, 
p. 68) only implemented the requisition functions of a shipboard ammunition manage¬ 
ment system. Neither Alderman (1986) nor Smith (1987) used objects and their re¬ 
lationships to model the data. 

E. ORGANIZATION 

This chapter has discussed the need for automating the shipboard ammunition 
management process, the scope of both the proposed ARM IRS database application 
and the scope of this thesis, and some of the general steps and tools used to define the 
ARM IRS design. 

The next chapter describes the current manual system for shipboard ammunition 
management. The manual forms and reports are discussed and the user's view of the 
ordnance management process is analyzed.5 The problem statement is further defined. 

4 DBASE III is a trademark of Ashton-Tate. 

5 LT Peter C. Lyle, US.NR contributed useful comments on Chapter II. 
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Chapter III updates and modifies the previously discussed prior work on the re¬ 
quirements analysis through the use of objects. The objects are identified and described 
using object diagrams and object specifications. The functional components (update, 
display, and control mechanisms) of ARM IRS are defined. Dataflow diagrams are used 
to describe the process. 

Chapter IV covers the transformation of the objects into a relational diagram. The 
menu-driven control mechanisms are defined with menu hierarchy diagrams. Finally, the 
logic specifications used to complete each menu option are listed in a Structured English 
format. 

Chapter V describes the use of the PARADOX DBMS package to demonstrate the 
implementation of the relations. The required internal and external reports are also de¬ 
fined. 

The final chapter briefly investigates a possible expert system interface and suggests 
other future work on automating shipboard ordnance management. 


II, THE SHIPBOARD AMMUNITION MANAGEMENT PROCESS 


The purpose of this chapter is to review the current manual system for managing 
ammunition aboard Navy ships. Before an automated system can be designed, we need 
to understand the functionality of the current system. It ir then possible to analyze 
problems and define solutions. This chapter first examines the forms and reports used 
in ordnance management. These forms and reports form the basis for the data require¬ 
ments discussed in the chapter that follows. The interface with external systems is ana¬ 
lyzed and a typical shipboard ammunition management scenario is presented. After 
defining these mission requirements, the problems with the current manual system will 
be discussed. 

A. SHIPBOARD FORMS AND REPORTS 
1. Inventory Records 

a. Master Stock Record Card 

The heart of the shipboard ammunition inventory' function is the Ammuni¬ 
tion Master Stock Record Card (XAVSUP Form 1296). One record card is maintained 
for each Xa\y' Ammunition Logistics Code (X’ALC) held in a ship's ammunition inven¬ 
tory. The NALC indicates the functional type of ammunition. Each NALC has one or 
more associated National Item Identification Numbers (XTIN). The XTIN further de¬ 
fines the specific type of ammunition. For example, one NALC identifies 12-gauge 
shotgun shells containing size 00 shot. Within that NALC, one particular NUN is for 
shells with a paper case while another NUN refers to shells with a plastic case (Smith, 
1987, p.l6). 

The Master Stock Record Cards, filed by NALC and then by NIIN, contain 
general information on the XTIN. This information includes: 

• Nomenclature (Short Title) 

• Unit of Issue (Packaging) 

• Shipfill or Mission Allowance 

• Training Allowance 

• Supply Cognizance Sj'mbol (COG) 

• Material Control Code (MCC) 

• Department of Transportation Hazardous Material Code 
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• Net Explosive Weight (NHEEW) 

• Coast Guard Hazardous Material Class 

• Shipboard Stowage Location 

• Remarks 

In addition, the record card contains a histor}' of transactions effecting the status or 
quantity of that NUN. Information on the current inventory balance is obtained from 
this section of the card. The card is organized into rows for up to 16 transactions. The 
column headings are: 

• Entry Date 

• Document Number (Activity + Date + Serial Number) 

• Quantity Received 

• Quantity Issued 

• Expenditure Type 

• Expenditure Quantity 

• Quantity Gn-Hand (Sei^'iceable) 

• Quantity On-Hand (Unservicable) 

• Anununition Transaction Report (ATR) Serial Number 

• Unexpended Training Allowance 

• Quantity Due In 

b. Lot I Location Card 

For each lot number (if any) within a NUN, lot card(s) (NAVSUP Form 
1297) are filed behind their master stock cards. Much of the information on this card is 
copied from the parent master card. The only additional information in the NUN de¬ 
scriptive section is a place for the lot number. The transactions section of the lot card 
is identical in format to the corresponding section on the master card except that a col¬ 
umn for consignee/consignor is added. The lot card is used to record transactions for a 
single lot. The transactions on each NTIN's lot cards is copied from the NUN master 
card. There is no information on the lot cards (except for lot number, of course) that is 
not also contained on the master card. 

c. Serial/ Location Card 

Some ordnance items are designated for increased tracking by assignment 
of unique serial numbers. For example, all missiles, all torpedoes and some mines 
(SPCCINST 8010.12D, 1988, p. 8-4-7) have serial numbers while gun ammunition does 
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not have an identifier for a single round. Items that require Serial/Lot Item Tracking 
(SLIT) have one or more Serial;Location Cards (NAVSUP Form 1356) filed behind the 
master card. SLIT controlled items may be serial number controlled (one or more serial 
cards for each master record card) or serial and lot controlled (io//i lot cards and serial 
cards for a single master record card). 

The serial cards contain most of the generic NUN information found on the 
master card (and lot cards). The transaction section has three additional columns: 

• Serial Number (each card has space for 17 serialized items, one for each row) 

• Maintenance Due Date 

• Condition (Servicable or Unservicable) 

Like the lot cards, the serial cards duplicate information found on their master cards. 

2. Requisition Records 

The goal of every ship is to maintain all of their ammunition allowance onboard 
or on order. Ships create orders for ammunition by transmitting requisitions. In general, 
these ammunition requisitions contain the following minimum information: 

• Document Number 

• Document Identifier 

• Requisition Addressees 

• Location for Receipt 

• NALC 

• NUN 

• Nomenclature (Short Title) [manual requisitions only] 

• Quantity Desired 

• Unit of Issue 

• COG Symbol 

• Project Code 

• Media Status Code 

• Signal Code 

• Demand Code 

• Advice Code 

• Fund Code 

• Priority Code 

• Required Delivery Date 
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• Remarks [manual and naval message requisitions only] 

• Classification 

The format of the above information varies with the type of requisition used. 
A ship may requisition ammunition using three different requisition formats: 

1. Defense Automatic Addressing System (DAAS) Message Requisition. These 
machine-read messages are prepared to an exact format specification (see 
SPCCINST 8010.12D, 1988, pp. 8-2-6 to 8-2-16). For example, these requisitions 
cannot contain remarks, are limited to only specified addressees, and must be un¬ 
classified. 

2. Naval Message Requisition. Requisition.- excluded from submission via DAAS are 
submitted via naval message. Requisitions that require narrative remarks or action 
addressees other than DAAS Dayton, Ohio are in this format. Like the DAAS 
requisitions, these requistions are transmitted from the ship via the Na\7 telecom¬ 
munications system. 

3. Manual Requisition. The DOD Single Line Item Manual Requisition Form (DD 
Form 1348) are hand-carried or mailed to a naval magazine or weapons station 
ashore. The requisition information is then entered into the CALMS system from 
the weapons facility's ADP equipment. DD Form 1348 is also used when ships 
lurn-in or off-load ammunition to shore activities. 

In addition to a file of requisitions (often containing all three formats) and 
turn-in documents, the ship maintains a locally prepared Requisition Log and Turn-In 
Log or a combination log summarizing both-requisitions and turn-ins. The requirement 
for and format of this record is r ^t specified by higher authority but is recommended 
because it greatly aids the assignn ent of document numbers and tracking of outstanding 
requistions. This log is list of document numbers (the identifier for requisitions and 
turn-in document) usually with columns for XALC, quantity, short title, and requisition 
status remarks. 

3. Transaction Records 

a. Ammunition Transaction Report 

Every action that results in a change to a ship's ammunition inventor)' (in¬ 
cluding receipt, issue, transfer, expenditure, loss, gain, or change in condition) must be 
reported (within 48 hours) in a prescribed report format (SPCCINST 8010.12D, 1988, 
p. 8-4-3). The ATR is a formatted naval message containing the following information: 

• Classification 

• Addressees 

• Reference (last ATR or other ATR referenced to) 

• Unit Identification Code (UIC) of reporting unit 

I. 
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• UIC of training allowance allocation command 

• ATR Serial Number 

• Julian Date of Transaction 

• Activity Classification Code (ACC) 

• NALC 

• NUN 

• Condition Code 

• Beginning Balance 

• Serial Number (if applicable) 

• Lot Number (if applicable) 

• Source UIC (for receipts) 

• Source Service Code (for receipts) 

• Expenditure Transaction Type 

• Reclassification Code 

• Ending Balance 

• Remarks 

As with the inventorj' information, ATR format varies with the type of 
control (Material Condition Code) applicable to that type of ordnance. The individual 
transaction lines in an ATR contain information that varies depending on whether the 
item is non-SLIT, SLIT reportable by lot, SLIT reportable by serial, or SLIT reportable 
by serial and lot. Another highly variable item on an ATR is the list of action and in¬ 
formation addressees which depends both on the location of the unit and the type of 
ordnance involved in the reported transaction. 

Each ship maintains a locally prepared ATR Log (often in addition to an 
ATR file) to summarize the command's ammunition transaction histoiy' and to assist in 
assigning correct ATR serial numbers. As with requisitions, it is essential that ATRs are 
received by addressees in the correct sequence with no unassigned or duplicated serial 
numbers. This log commonly consists of rows for each ATR serial number with columns 
for message date-lime group, NALC(s), type of transaction, and ending balance. 
b. Ammunition Reclassification 

Ammunition is reclassified when external inventorj' or technical managers 
determine that a particular item or lot should be used in a limited fashion or considered 
unserviceable. This reclassification can be the result of ammunition malfunction, tests. 
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shelf-life expiration, or quality evaluation (NAVSEAINST 8015.1A, 1988, p. XI-1). If 
the affected ammunition is not properly marked when reclassified, both in the magazine 
and on the inventorj' record, serious personnel injuries or weapons systems damage can 
result. In addition, mixing serviceable and unserviceable ammunition aboard ship pre¬ 
sents an explosive safety hazard. 

Ships periodically receive Notices of Ammunition Reclassification (NAR) 
messages listing ammunition with a revised condition code. These serialized messages 
are then checked against the ship's ordnance holdings to determine applicability. If the 
ship holds the referenced ammunition, the ordnance is tagged, inventory cards are up¬ 
dated, an ATR is transmitted to show the revised condition code, and action is taken 
depending on the new condition code. All NAR messages are filed until incorporated 
into the (approximately annual) revision to the Naval Sea Systems Command 
(NAVSEA) publication listing all Naty ammunition that is unserviceable, suspended, 
or of limited use (NAVSEA TWO24-AA-ORD10, 1989). 

B. INTERFACE WITH EXTERNAL SYSTEMS 

The current shipboard ammunition management system does not exist in isolation 
from inventory management at higher levels. The forms and reports discussed above 
exist not only to assist shipboard decision makers in managing ordnance inventories but 
serve to keep higher eschelon commanders informed of ammunition inventories for the 
squadron, group, and fleet. While the automation boundary of the proposed AR.MIRS 
system stops at the brow of a single ship, it is important to recognize the place of 
shipboard ammunition management in the larger scheme of Nav\'-wide logistics. 

The Na\y's Conventional Ammunition Integrated .Management System (CALMS) 
is directed by the Navy Ship's Parts Control Center (SPCC) at .Mechanicsburg, 
Pennsylvania. CALMS is an integrated management information system using large scale 
automatic data processing equipment designed to provide daily updates of ammunition 
inventories to Fleet-level and Naty Department commanders (OPNAVINST 8000.13, 
1971, p. 3). It is therefore the Nav\''s central repositor}' of ammunition inventory infor¬ 
mation. However, CALVIS is more than just an inventorj’ tool. It is also used for read¬ 
iness assessment, operational decision making, technical evaluation, procurement 
planning, and budget determination (Swanson, 1977, p. 23). The ATRs submitted to 
SPCC form the interface between the ship and the central CALMS database. SPCC 
provides information to ships in the form of quarterly reconciliation reports. These re¬ 
ports reflect data on selected items from the ship's inventory according to the CALMS 
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database. The reconciliation report is compared to the (manual) inventorj' records and 
CAIMS is updated with an ATR from the ship. SPCC also provides feedback to ships 
on erroneous ATRs. For e.xample, a ship is notified by naval message if there is a 
missing ATR or if an ATR serial number out of sequence. 

The Naval Ordnance Management Information System (NOMIS) is installed at 
major ordnance facilities ashore.6 The NOMIS stock records are the oflicial inventory 
records of the weapons station. This system provides information support for the receipt, 
storage, segregation, issue, and movement of conventional ammunition ashore 
(NAVSEAINST 8015.lA, 1988, p. 2). ATRs from shore installations are transmitted to 
CAIMS via AUTODIN. Just as in the ship-to-CAIMS interface, accurate and timely 
transaction reporting is the cornerstone of CAIMS accuracy. The interface between 
NOMIS and the fleet is through the requisitions and turn-in documents generated 
onboard. 

C. PROCESS SCENARIO 

The following sample transaction histor}' (adapted from SPCCINST 8010.12D, 
1988, p. 12-1-Bl) illustrates how the forms, reports, logs, and files discussed above are 
used together in a typical shipboard ammunition management situation.? While this 
scenario does not fully describe the information flow and requirements of ARMIRS, it 
does help illustrate characteristics of the current manual system and aids in defining the 
problems with the status quo. 

1. (900210) Opened new master stock record card with quantities carried over from 
previous records. Posted 746 to ONHAND BALANCES (CONDITION CODE 
"A") and 150 to UNEXPENDED TRAINING .ALLOCAT10N.8 Itemize the 
master card quantity by lots and copy the information to the new lot cards. 

2. (900312) Fired 63 rounds in a gunnery exercise. Post 63 to Transaction Type "F". 
Update the balance to show 683 in Condition Code "A". Reduce UNEXPENDED 
TRAINING ALLOCATION to 87. Use the ATR Log to locate the next ATR se¬ 
rial number. Post the ATR serial number to the master card. Copy information to 
the lot cards. Draft an ATR message and file a copy. 


6 WPNSTA Charleston. WPNSTA Concord, WPNSTA Earle, WPNSTA Seal Beach, 
WPNSTA Vorkto-.vn, NAVORDSTA Indian Head, and NAVUSEAWARENGSTA Keyport. 

7 The scenario is for 5-inch gun projectiles aboard a destroyer. 

8 Note that UNEXPENDED TRAINING ALLOWANCE is on a fiscal year basis and is 
reduced any time a training, test, or operations expenditure in posted. A balance cannot be carried 
over to a new fiscal year. The amount of the authorized Training Allowance (formally known as 
the Non-Combat E.xpenditure Allowance, or NCEA) is entered on 01 October of each year. 
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3. (900313) Requisition 63 rounds to replace the ammunition used in yesterday's 
gunner}' exercise. Use the requisition log to ensure that the next requisition serial 
number is used. Post requisition R5406650728009 to DOCUMENT NUMBER and 
post 63 rounds to QUANTITY DUE IN’. 

4. (900325) Fired 12 rounds for test. Post 12 to Transactions, Type "G". Reduce 
ONHAND Condition "A" to 671 and UNEXPENDED TRAINING ALLO¬ 
CATION to 75. Prepare the next ATR message and post the report serial number 
to the ATR block on the master card. Update the quantity on the lot card. 

5. (900429) Received the 63 rounds ordered last month. Post R5406600728009 to 
DOCU.MENT NUMBER and Transaction Type C. Increase Condition Code "A" 
amount to 734. Reduce QUANTITY DUE IN to 0. Update the Requisition Log. 
If these new rounds are from a dilferent lot, create a new lot card and transfer the 
information from the master card. Prepare an ATR and update the ATR Log. 

6. (900515) Receive a Notice of Ammunition Reclassification (NAR) regarding the 
suspension of one lot. Post quantity 21 to Transaction Type "X". Reduce Condition 
Code "A" to 713 and open a balance of 21 in Condition Code "J". Prepare an ATR 
to report the change in Condition Code. 

7. (900604) Fired 32 rounds in another gunnery exercise. Posted 32 to Transaction 
Type "F". Reduce Condition Code "A" to 681. Reduce UNEXPENDED TRAIN¬ 
ING ALLOWANCE TO 43. Prepare ATR message and post the report serial 
number to the ATR block on the master card. Update the lot card. 

8. (900704) Receive a NAR regarding the lot in Condition Code "J". The lot is de¬ 
clared unserviceable. Post 21 rounds to Transaction Type "X" and Condition Code 
"H". Reduce Condition Code "J" by 21. Prepare an ATR to show the change in 
Condition Code. 

9. (900806) Offload the 21 unserviceable rounds at Naval Magazine Lualualei, HI. 
Prepare a DD Form 1348 turn-in document and enter the document number on the 
master card and in the Turn-In Log. Adjust the quantities on the inventory card, 
decreasing Condition Code "H" by 21. Prepare an ATR to report the transfer. 

D. PROBLEM DEFINITION 

The preceding overview of the current manual system for shipboard ammunition 
management helps define some of the problems with the exisiting system; 

• The system is inefficient because it often requires the same information to be writ¬ 
ten more than once (e.g., copy data from master cards to lot or serial cards). 

• Filing of inventor}' cards only by NALC and NUN limits the flexibility and value 
of the system. Sorting and displaying ammunition inventor}' information by other 
attributes would require annotating and refiling each card. 

• Extracting information from many inventory cards, logs, files, and publications is 
time consuming. 

• There are no reliable and easily accessed indicators of undesirable situations (e.g., 
expired maintenance due dates, low stock levels, or low training allowance bal¬ 
ances). 
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• Working with the current system is highly repetitive and can be especially frus¬ 
trating for inexperienced personnel. 

• The error-prone manual ammunition management system undermines the reliabil¬ 
ity of the Nav 7 -wide CAIMS database which depends on accurate and timely 
transaction reports. 

• The manual preparation of complex and time-consuming forms and reports (espe¬ 
cially ammunition transaction reports and requisitions) is an inefficient use of per¬ 
sonnel. 

This chapter has defined the data and processes involved in the current manual 
system of afloat ordnance management. An analysis of these forms, reports, and proce¬ 
dures helps define the problem domain. In the next chapter, an information model is 
used to describe the vocabular>’ and conceptualization of this problem domain. 









III. REQUIREMENTS VERIFICATION 


The previous chapter defined the problem domain for shipboard ammunition man¬ 
agement. This chapter is concerned with building a model of the information in that 
domain. This information model identifies and abstracts what is in the problem. Similar 
"things" in the problem are identified and abstracted as objects We will see how this 
process of object definition helps formalize knowledge about ordnance management on 
U.S. Na \7 ships. After the objects are defined, a model of the system's data (i.e., object) 
flows is constructed to aid application analysis. 

A. DATA REQUIREMENTS 

I. Object Oveniew - Modeling the User's View 

An object, as defined by Shlaer and Mellor (1988, p. 14), is an abstraction of a 
set of real-world things such that (1) all of the real-world things in the set (the instances) 
have the same characteristics, and (2) all instances are subject to and conform to the 
same rules. These two characteristics help define objects that allow simple operations 
on the data that are easy to understand and easy to get right. 

Identifying the objects in shipboard ammunition management is straightfor¬ 
ward. Wc start by asking. "What are the things in the ordnance inventory, requisitioning, 
and reporting problem?" These ammunition-related things fall into two broad categories: 
(1) tangible things, and (2) incidents or interactions. 

Tangible things are the easiest objects to find. Given the problem discussion in 
the last chapter, we clearly have ammunition as a tangible object. But we have different 
requirements for capturing information on this ammunition. Is it ammunition we have 
onboard (A.VIMO INVENTORY object) or ammunition we want to obtain (REQUI¬ 
SITION and LINE ITEM objects)? It is also important how this ammunition is con¬ 
trolled and accounted for. Some ammunition is uniquely identified by the serial number 
on an individual piece of ordnance. Other rounds are identified by just a lot number. 
Requirements also exist to identify some ammunition by both serial and lot number. 
Some ammunition has neither lot numbers nor serial numbers. These different views of 
the problem require different objects. In addition, we need to capture information about 
our ship and about the ship or weapons station participating in our ammunition trans¬ 
actions (COM.MAND object). From our knowledge of the tangible things involved in 
ammunition management, the following objects are easy to identify: 
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COMMAND 

• REQUISITION 

• REQN LINE ITEM 

• AMMO INVENTORY 

• LOT CONTROLLED AMMO 

• SERIAL CONTROLLED AMMO 

• SERIAL & LOT CONTROLLED AMMO 

Incident or interaction objects represent an event (something which happens at 
a specific time) or have a "transaction" quality (relating to two or more other objects in 
our model). Incidents (like expending ammunition during a gunnery exercise) or trans¬ 
actions (like receiving requisitioned torpedoes from the naval weapons station) result in 
changes to a ship's ammunition inventor^^ Information about these changes is captured 
in the TRANSACTION object. 

Object diagrams, like those in Appendix A, are pictures of the user's perception 
of an object in the work environment. These objects diagrams help to summarize 
knowledge of an object and to present it visually and unabiguously. The diagrams in 
Appendix A follow the object diagram conventions of Kroenke and Dolan (1988, pp. 
91-97). The eight objects in the ARMIRS database are represented as eight boxes. Inside 
each box is a list of all properties of that object. Some of the properties are written in 
lowercase letters, while others appear in uppercase letters and are enclosed in boxes 
themselves. Some of these properties have the letters MV next to them. The paragraphs 
that follow examine the object diagrams in Appendix A while discussing the object 
properties. 

2. Object Descriptions 

a. COMMAND Object 

The COM.MAND object (Figure 1) includes ten properties. Each property 
represents an important characteristic of the ship or shore activity involved in an am¬ 
munition transaction, such as the unit identification code (UIC), the ship or station 
name (Name), and descriptive information about the ammunition in the command's in¬ 
ventory (A.M.MO INVENTORY - MV). The first eight properties listed (see Appendix 
A) are non-object properties. The last two, which are capitalized and enclosed in boxes, 
are object properties. An object property is a characteristic of the entity that is actually 
another object (Kroenke and Dolan, 1988. p. 91). As a result, there are other object di¬ 
agrams for REQUISITION and A.MMO INVENTORY. The REQUISITION object 
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will contain properties of the ammunition requisitions sent by a ship and the AMMO 
INVENTORY object will contain properties of the ordnance held onboard. This is an 
example of one object "containing" other objects. Since a command instance is uniquely 
identified by a LTC, this object identifier is distinguished from the other properties by 
an asterisk in the object diagrams. 

The COMMAND object includes properties that are allowed to have a 
single value while others are allowed to have multiple values. For example, a command 
instance is allowed to have only one value for LTC. However, AMMO INVENTORY 
and REQUISITION are allowed multiple values (indicated by the letters MV) because 
a command holds many inventory items (the instances represented by the Master Stock 
Record cards) and many requisitions (each instance is an entry in the command's Req¬ 
uisition Log or File).9 

b. REQUISITION Object 

The REQLTSITON object (Figure 1) contains general information about 
ammunition requisitions sent from one command and filled by another. This object does 
not contain desired NTINs or quantities. That information is found in REQN LINE 
ITEM. The instance of the REQUISITION object is a single requisition header (either 
DAAS, naval message, or DD Form 1348) uniquely identified by a document number. 
A requisition contains one or more line items (described in detail in the REQN LINE 
ITEM object) for each type of ammunition desired. A requisition also includes a docu¬ 
ment identifier and security classification and may contain remarks (depending on the 
requisition format chosen). The requisition is addressed to multiple action or informa¬ 
tion addressees in accordance with fleet instructions and depending on the type of ord¬ 
nance desired. 

c. REQN LINE ITEM Object 

The information in this object (Figure 2), found at least once in ever}' req¬ 
uisition, is represented by a single line on an ammunition requisition. A separate line is 
used for each NUN. For example, on a single requisition for Harpoon missiles, shotgun 
rounds, and signal flares, we would find three different line items. Each line item contains 
information on the quantity desired as well as the desired delivery date. A requisition line 
may have a classification different (but not higher) than the entire requisition. Since a 

9 As Kroenke and Dolan (1988, p. 94) point out, whether a property is single or multiple¬ 
valued has nothing to do with whether it is an object or non-object property. Note that the 
COMMAND object happens to contain single-valued, non-object properties and multi-valued, 
object properties only by coincidence. 
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line item is associated with only one requisition, the REQUISITION object is a single¬ 
value, object property of this object. (Obviously a line item does not exist alone without 
a requisition header.) A line item instance may be associated with one Master Stock 
Record Card so that many of the properties of INVENTORY (i.e., unit of issue and 
COG symbol) are "contained" in the REQN LINE ITEM object and found on ammu¬ 
nition requisitions. 

d. AMMO INVENTOR Y Object 

An instance of the AMMO INVENTORY object (Figure 3) is the descrip¬ 
tive header on a single Master Stock Record Card. With instances uniquely identified 
by NUN, this object captures information on ammunition held by a command (i.e., al¬ 
lowance, shipboard location(s), and COG symbol). The history' of inventory balance 
changes for that NUN is captured in the TRANSACTION object discussed below. The 
AMMO INVENTORY object also contains the total quantity on hand as posted from 
ammunition transactions. Associated with an AMMO INVENTORY instance may be 
one 01 more lot controlled, serial controlled, or serial and lot controlled objects. REQN 
LINE ITEM is also a multi-value, object property of AMMO INVENTORY, 
c. LOT CONTROLLED AMMO Object 

Lot controlled ammunition (Figure 4) is uniquely identified by lot number 
and has one or more shipboard stowage locations. AMMO INVENTORY is a single¬ 
value, object property here because of the one-to-many relationship between the Master 
Stock Record Card (AMMO INVENTORY properties) and the Lot/Location Card(s) 
(LOT CONTROLLED AMMO properties). TRANSACTION is a multi-value object 
property since one ammunition lot has one or more transactions. 

/. SERIAL CONTROLLED AMMO Object 

The serial number is the object identifier for this object (Figure 4). The 
non-key attributes include maintenance due date, type of maintenance due code, and a 
stowage location. As with the LOT CONTROLLED AMMO object, AMMO INVEN¬ 
TORY is a single-value, object property here. In addition, the TRANSACTION object 
is a property of SERIAL CONTROLLED ammunition. One serial number has one or 
more associated transactions. 

g. SERIAL & LOT CONTROLLED AMMO Object 

This object includes all of the properties found in the previous object with 
the addition of the lot number. 
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h. TRANSACTION Object 

A TRANSACTION instance is represented by one of the lines on the bal¬ 
ance histor}' section of a Master Stock Record Card. This object (Figure 5) therefore 
includes AMMO INVENTORY as a single-value, object property. Ever}' balance 
change is uniquely identified by a single line on a serially numbered ATR. Every ATR 
has multiple addressees. Single-value, non-object properties of this object include the 
transaction date, the old balance, the quantity issued/received/expended, and updated 
condition code. Since a TR.4NSACTION can involve any of the three ammunition 
control categories discussed above (or none of them for non-SLIT transactions), a di¬ 
agonal line in the corner of these object boxes indicates that only one (or none) of these 
object properties may apply in a TRANSACTION instance. 

3. Object Speciflcations 

Appendix B presents the complete object specifications for ARM IRS. The ap¬ 
pendix consists of two parts: (1) object definitions, and (2) domain definitions. Object 
definitions, as used by Kroenke and Dolan (1988, p. 108), list all the properties of an 
object and indicate the domain from which values for each property can be drawn. The 
domain definitions specify formats, lengths, and special restrictions on the values of each 
domain. Note that the domain definitions are separate from the object definitions. This 
helps reduce duplicate domain definitions because one domain may be used for multiple 
properties. For example, the same domain (Navy command names) can be used for both 
COMMAND.Names and REQLTSITION.Addressees. 

The object specifications in Appendix B are detailed enough to be used for the 
next phase-database design. 

a. Object Definitions 

The object specification syntax used by Kroenke and Dolan (1988, pp. 
108-110) is used is this work. The first part of Appendix B includes the object definitions. 
All of the properties of an object are listed. A semicolon separates the name of each 
property from its domain. If the domain is another object but only some of the proper¬ 
ties are carried over to the object being defined, then the word SUBSET is used and the 
properties of the foreign object are enclosed in brackets. For example, COMMAND is 
a foreign object in AMMO INVENTORY, with only the properties UIC, Name, and 
Hull Number applicable to the user's view of COMMAND data in AMMO INVEN¬ 
TORY. 
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b. Domain Definitions 

The second part of Appendix B contains the domain definitions which de¬ 
scribe the set of values from which an instance of a property may be drawn. These do¬ 
main definitions also follow the Kroenke and Dolan (1988, p. 110) syntax. They include 
both physical and semantic descriptions. The physical description may contain a mask-a 
restriction on the allowable values. For example, "Fund codes" is a domain whose de¬ 
scription includes a mask specifying that the first digit must be a letter and that the last 
digit must be the number six. In the physical descriptions, "numeric" means the digits 0 
through 9, "alphabetic" means the letters A thorough Z, and "text" includes letters, 
numbers, and symbols. 

B. APPLICATION (FUNCTIONAL) REQUIREMENTS 
1. Dataflow Diagrams 

One widely used tool for studying business functions is the dataflow diagram. 
Dataflow diagrams (DFDs) help determine how the organization creates, edits, deletes, 
and displays objects. DFDs also serve as a clear and convenient communication tool for 
users and analysts. Even in situations where automation is not of interest, DFDs are 
used for problem analysis. For example, this tool has been used to document and ana¬ 
lyze physical product flows in manufacturing firms as well as information flows in service 
organizations (Kuehn and Fleck, 1990, p. 10). 

As Yourdon (1989, p. 140) pointed out, DFDs are particularly valuable for op¬ 
erational systems in which the functions of the system are of paramount importance and 
more complex than the data that the system manipulates. The DFD is just one of the 
modeling tools available to study the shipboard ammunition management process. It 
provides only one view-the functional view. The DFD is a useful tool in AR.VIIRS 
systems analysis because it aids in representing the key functions of the current manual 
system and helps identify the flow of data and the actions on objects. 

This thesis uses the popular "Yourdon and DeMarco Methodology" for DFDs 
and follows the conventions used in Yourdon's (1989, pp. 139-187) classic work. The 
diagrams in Appendix C illustrate the use of typical Yourdon-style components in a se¬ 
ries of leveled diagrams. These components include the process, the flow, the store, and 
the terminator. 

The first component of the DFD is known as the process, represented graph¬ 
ically by a circle. The process is named with a verb-object phrase that describes what the 
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process does such as GENERATE REQUISITIONS, MANAGE INVENTORY, or 
GENERATE REPORTS. 

The flow is represented graphically by an arrow in or out of the process. The 
flow describes the movement of data packets from one part of the system to another. 
As shown in the diagrams in Appendix C, the packets carried by these flows could be 
physical objects such as ONLOADED AMMO. Flows can be split into several more 
elementary' data packets. For example, the dataflow ALLOWANCE in Figures 6 and 7 
is split in Figure 8 into MISSION ALLOW, NCE ALLOW, and SHIPFILL ALLOW. 

The store models a collection of data packets at rest. The notation for the store 
is two parallel lines. A store might consist of ammunition stock records in a card file or 
ammunition requisitions in a file folder. Figure 7 shows the five stores in the manual 
ammunition management system. 

The context DFD (Figure 6) shows the terminators (sources and sinks) in the 
system; they are graphically represented by a rectangle. Terminators are the external 
entities with which the system communicates These entities (like "User" in Figure 6) may 
be internal to the organization but outside the control of the system being modeled. In 
the ammunition management environment, these terminators include the shipboard user, 
the weapons station or other ship, DAAS, SPCC, and NAVSEA. 

The ARMIRS bubbles (processes) are numbered according to Yourdon's (1989, 
pp. 165-171) hierarchical system of leveled diagrams. Figure 6 consists of only one bub¬ 
ble (Process 0) representing the entire system; the dataflows show the interfaces between 
the shipboard ammunition management process and the external terminators. As shown 
by Figure 7, the DFD directly below the context diagram (called the Level 0 Diagram) 
represents the top-level view of the three major functions of the system, as well as the 
interfaces between those functions. These bubbles arc numbered 1, 2, and 3. Each of 
these three processes is associated with a lower-level DFD (Figures 8, 9, and 10 respec¬ 
tively). 

2. Description of Dataflow 

The DFDs can be examined by tracing the flow of data in Figure 7 using the 
objects defined in the preceding sections. In Process 1 (Manage Inventory), the Gunnery 
Ofllcer'Petty OflTicer updates information on the ship (CO.M.MAND object) as required 
and uses updated fleet instructions and references to update the ARMIRS rule base 
(e.xplained in greater detail later in this thesis). The inventory’ cards (representing the 
AMMO INVENTORY, SERIAL, LOT, and SERIAL & LOT CONTROLLED 
AMMO objects) are updated as onloaded ammunition is received and checked. Other 
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inventor}' modifications (new instances of the TRANSACTION object) are generated 
when ammunition is expended. Updated allowances are also processed and Notices of 
Ammunition Reclassification (NARs) are compared to the AMMO INVENTORY in¬ 
stances to determine which NARs pertain to the command. 

The process of generating requisitions (Process 2) begins with the user's decision 
on desired ammuntion. After reviewing the Requisition File (representing properties in 
the REQUISITION object) and using ship (COM.MAND object) information with the 
system rules, a requisition header (new instance of the REQUISITION object) is cre¬ 
ated. After selecting the desired requisition format, multiple items (REQN LINE ITEM 
object) are added to the message header to include the desired ammunition. After the 
requisition is sent, requisition status messages are periodically received onboard. The 
information from these messages is used to update entries in the Requisition Log (up¬ 
dating the REQN LINE ITE.M and REQN objects). A similar, but simpler, process is 
used to generate turn-in documents. Only one format is used for the DD Form 1348 
turn-in document that accompanies offloaded ammunition. 

The third major function of the shipboard ammunition management system 
generates internal and external reports. Internal summar}' reports may draw data from 
all the files (and from all the objects) in the system to produce a variety of reports for 
shipboard decision makers in response to user queries. For example, Serial'Location 
cards in the inventor}' card file (SERIAL and SERIAL & LOT CONTROLLED 
AMMO objects) are reviewed for a report on ordnance with soon-to-expire maintenance 
due dates. Allowance data from the Master Stock Record Cards (AMMO INVEN¬ 
TORY object) is compared with current balance (posted from TRANSACTIONS) to 
produce a report allowing the tracking of training allowance expenditures throughout 
the fiscal year. ATRs are also produced by Process 3. Every inventory transaction 
(corresponding to new instances of the TRANSACTION object) requires a transaction 
report that draws information from the inventor}' cards (and objects), the ship (COM¬ 
MAND object) information, and the rule-based expertise (e.g., determining the ATR 
addressees). 

The dataflow diagrams in Appendix C illustrate the three key ARM IRS func¬ 
tions discussed above: inventor}' processing, requisition management, and report gener¬ 
ation. Obviously some of these processes seem to overlap (e.g., both Process I and 
Process 3 update instances of the TR.ANSACTTON object). Figure 11 in Appendix C 
helps relate the three ammunition management functions to the ejght objects defined 
earlier in thi.' chapter. Rather than using several logs and files to store information, a 
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single database is used to store the objects. The three ARM IRS functions read and/or 
write object information as shown by the arrows in Figure 11. The specific functional 
components of these applications and objects are discussed in the following sections. 

3. Application Functional Components 
a. Inventory Management 

The inventor)' management process (Process 1) reads and writes four objects 
as discussed below: 

(1) Read and Write the COMMAND Object. As shown in the Level 0 
.Diagram (Figure 7), the Gunner)' Officer (through Process 1) writes the COMMAND 
object which is later read to generate requisitions (Process 2) and reports (Process 3). 
Figure 12 in Appendix D shows the form used to both update and display the COM¬ 
MAND object. When the ARM IRS system is first installed aboard a ship, the Database 
Adminstrator enters the LTC, command name, hull number, and service code. This in¬ 
formation will not change as long as the system remains onboard and the ship remains 
in commission. As the ship's location and fleet commander change, this form is also used 
to update the database. For each requisition or transaction, information on the other 
command involved (either another ship or a weapons station) is entered. This form is 
also used to display command information even when updating is not required. 

{2/ Read and Write the AMMO INVENTORY Object. As shown in 
Figure 11, the inventor)' management process reads and writes ammunition inventory 
data. This information is entered into the database by a form similar to the one shown 
in Figure 13. This form captures information in the AMMO INVENTORY object and 
is similar to the Master Stock Record Form used in the manual system. The upper part 
of the form is used to record descriptive information (AMMO INVENTORY object) 
about a particular NUN held in inventory. This form, like the Command Information 
Form discussed above, is used both to update (including creation or modification of an 
object instance) and display information in response to user queries. For example, if the 
user wished to see all of the inventory records for torpedoes, he would enter the torpedo 
COG of 4T in the "COG" field in Figure 13. Using the query-by-example facility, the 
user would then be able to page through a series of inventory screens (Figure 13) for 
torpedoes. As a result, the inventory form is a dual purpose form. Some of the data in 
the form's fields would be typed in by the user and others would be provided by the 
database, depending on whether append (update for a new instance), update, or display 
options were selected from a system menu. 

\ 
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The update and display mechanisms used with this object (as well as 
for the other objects discussed below) are fully described in Appendix E. 

(3) Read and Write the TRANSACTION Object, Changes to the com- 
mand's ammunition inventory are made through use of the form shown in Figure 13 and 
discussed above. The middle part of that form is used to update and display information 
on how the inventory quantity and condition have changed (TRANSACTION object). 
The bottom area on the Figure 13 form is used for more detailed information on the 
ATR generated (from the TRANSACTION object) for each transaction. For example, 
in an ammunition receipt transaction, the quantity, date, and document number of the 
DD Form 1348 accompanying the ammunition would be entered. The system would add 
the old balance to the quantity received to give a new balance. This quantity is then 
posted to the AMMO INVENTORY object and becomes the balance brought fonvard 
for the next transaction. The expert database system discussed in Chapter VI (when 
used) would provide the information on the "Addressees" field of Figure 13. In addition, 
the lower part of the Serial, Lot Information Form (Figure 14) is used to display 
TRANSACTION data for ammunition with serial and/or lot numbers. Appendix E de¬ 
scribes the adding (posting), editing, and deleting of TRANSACTION instances. 

(4) Read and Write LOT, SERIAL, and SERIAL & LOT AMMO 
Objects. The form shown in Figure 14 is also used to update and display database in¬ 
formation on serial and lot ammunition in the inventory. The serial and/or lot number 
is entered on the top part of the form. The lower part of the form, drawn from the 
TRANS,4CT10N object, allows update and display of inventory transactions affecting 
SLIT-controlled items. For example, to display information on a particular Harpoon 
missile, the serial number would be entered and the form (corresponding to both the 
Scrial.'Location and Lot/Location cards in the manual system) would be displayed with 
all applicable data fields completed. If the user did not have the serial number available 
but knew the N'ALC for Harpoon missiles, the NALC would be entered in the querj’- 
by-forms mode and the user could page through a series of screens, one screen for each 
Harpoon missile onboard. 

b. Requisition and Turn-In Generation 

The requisition and turn-in generation process uses the the forms discussed 
above and the Requisition Information Form (Figure 15) to: 

(1) Read the COMMAND Object, The COM.M.4ND object is used by 
this process to furnish data on the originating and receiving commands for ammunition 
requisition and turn-in documents. 
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C2) Read the AMMO INVENTORY Object, Turn-in documents and 
requisitions use descriptive ammunition information from this object. 

(3) Read the TRANSACTION Object, As discussed in the detailed 
functional component descriptions (Appendix E), the generation of turn-in documents 
requires TRANSACTION information. 

(4) Read SERIAL and;or LOT CONTROLLED AMMO Objects, If a 
turn-in item is controlled by serial number or lot number, then the applicable object 
must be read by this process to generate turn-in documents. Items are not requisitioned 
by specific serial or lot numbers. 

(5) Read and Write REQUISITION and REQN LINE ITEM 
Objects, Ammunition requisitions are created, updated, and displayed using the form 
shown in Figure 15. To create a new requisition, the user would enter all the information 
shown on the form. REQUISITION object information is used to construct the message 
header. The individual REQN LINE ITEM instances are created by completing the 
lower half of the form. As requisition status messages on these line items are received 
by the ship, the "Status" field is updated. To review a requisition, the user would type 
in the document number in the appropriate field and the system would display that 
requisition. 

c. Generate Reports 

This process reads all eight ARM IRS objects to produce ATRs and internal 
reports. In addition. Process 3 writes TIU^NSACTION data to the database when the 
ATR serial number is assigned to a transaction. 

4. Interapplication Requirements 

Coordination of data processing and the sequential relationship between Process 
1 (Manage Inventor}’) and the other processes (Generate Requisitions and Generate 
Reports) require that initial data entry about the ship and the ammunition inventory be 
completed before the system can be fully utilized. This initial entrv is accomplished using 
the forms shown in Figures 13 and 14 as previously discussed. If an item is controlled 
by serial and;or lot number, a Master Stock Record must be created before transactions 
can be applied and posted. Transactions to SLIT items must be processed through the 
transaction section of the form in Figure 13. As in the manual system, a Serial Lot 
Record cannot e.xist without the parent master record. 

A prerequisite for full use of the requisition generation function (Process 2) re¬ 
quires information on the commands involved (using Figure 12) as well as user input on 
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the type and quantity of ammunition desired (using the form in Figure 15). The user 
must also select a requisition format in order to output a requisition. 

In a similar way, Process 3 (Generate Reports) requires that the database al¬ 
ready contain information on ammunition and requisitions before selected reports can 
be considered complete and accurate. Transaction reports can be generated only after 
the inventor)’ has been updated to reflect the balance changes. In addition, operation 
of the ATR e.xpert database system (or user input if the expert system is not used) must 
be completed before an ATR is ready for transmission. 

5. Operations Requirements 

a. System Operation 

Because of the high frequencies and volumes required for the update and 
display activites shown in Appendix E, full use of ARM IRS requires a robust and de¬ 
pendable system. It is especially important that the system is fully operational during 
periods of high anununition transaction volume. These periods include: 

• Immediately prior to a deployment when major ammunition onloads are scheduled. 

• Before an overhaul period when ship-wide offloads are required. 

• After drydock periods when ammunition magazines must be refilled. 

• During refresher training and other training periods when expenditure of ammuni¬ 
tion is high. 

• After combat operations requiring ammunitiomexpenditure. 

• Prior to repairs in or near ammunition magazines requiring a partial offload. 

b. Backup and Security 

Procedures for system backup and security contribute toward the overall 
operational readiness of AR.MIRS. Backups are recommended after everj’ three to four 
minor transactions or weekly (whichever comes first). More frequent backups may be 
required if system volumes and frequencies exceed those shown in Appendix E. In addi¬ 
tion, a backup copy of the supporting microcomputer DBMS should be stored in a se¬ 
cure location. Strict enforcement of backup procedures will simplify the task of data and 
system recovery. 

Although an essential component of a working AR.MIRS system, backup 
procedures and logic are not specified in this thesis. A variety of generic microcomputer 
backup tools are commercially available. Custom design of AR.MIRS-specific backup 
software is not necessary when compatible backup software is so common. 
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The security of ARMIRS data also requires attention. Some ARMIRS data 
(e.g., some ATRs and requisitions) and the ammunition inventory taken as a whole are 
classified Confidential. Password administration and control, assigned access, physical 
security of the microcomputer (and backup data disks), and protection against compro¬ 
mising electronic emissions are required. As with backup systems, software already exists 
to encrj’pt data and protect against unauthorized access. Although essential to eventual 
implementation, the specific security software selected does not impact database design 
and is beyond the scope of this thesis. 
c. Users 

The users of ARMIRS data include: 

• Routine Users: Gunnery Officer, ASW Officer, Gunner's Mates (Gun and Missile) 
and Torpedomen. 

• Database Adminstrator (Weapons Officer) to establish and enforce procedures for: 

■ Database backup and recoveiy 

■ Data and system security (passwords and physical security) 

■ System application maintenance 

■ Training of system users 

• Occasional (Query Only) Users: CIC Officer, Operations Officer, Commanding 
Officer, and inspectors receiving ARMIRS information through reports processed 
by routine users as intermediaries. 

6. Administrative and Environmental Requirements 

As Database Administrator (DBA), the Weapons Officer will supervise opera¬ 
tion of AR.MIRS. In addition to the specific responsibilities listed above, the DBA will 
be responsible for initial system setup and bulk data entry. During initial conversion 
from the manual system, a large volume of database entries will be made as data is 
transferred from the stock record cards, ATR logs, and requisition files. An improved 
sytem for this initial bulk data entry could be implemented in a later version of 
ARMIRS. 

The unique and demanding shipboard environment imposes additional con¬ 
straints on hardware requirements. TEMPEST-approved Zenith 248 microcomputers 
(PC ATIO equivalents) and printers are available on many Navy* ships and could be uti¬ 
lized for ARMIRS use. 


10 PC and PC AT are trademarks of International Business Madtincs Corporation. 
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IV. LOGICAL AND APPLICATION DESIGN 


This chapter uses the objects and relationships defined in Chapter III to develop the 
ARM IRS relational schema. This view of the object relationships, together with the 
previously discussed objcct/data flows, is then used to design the application menus. 

A. LOGICAL DESIGN-TRANSFORMATION OF OBJECTS 

The transformation of the ARMIRS objects into relations is described below for 
each object. The overall view (schema) of these relations is shown in Appendix F. 

1. COMMAND Object 

The COMMAND object consists of two multi-valued object properties (REQ¬ 
UISITION and AMMO INVENTORY) and eight non-object properties. An instance 
of COM.MAND is a Na \7 activity identified by a Unit Identification Code (LTC). The 
relation shown in Appendix F shows COMMAND (with UIC as the key attribute) as 
the parent relation and REQUISITION (keyed on Document Number) as one child and 
AMMO INVENTORY (with NUN as the key) as another. 

Both relationships are described as one-to-many. This type of relationship is 
shown as a forked line, with the fork on the "many" side of the relationship. One com¬ 
mand has many NIINs in its ammunition inventory and many Document Numbers in 
its Requisition Log. In a one-to-many relationship, the key of the parent relation (UIC) 
is placed as a foreign key in the child relation. Both relationships have a mandatory-to- 
optional constraint. Every requisition must belong to a command (actually two COM¬ 
MANDS, the ARMIRS ship [S_LTC] and the other command involved in a transaction 
[0_LTC]). However, it is possible to have a command without a requisition. An inven¬ 
tory item exists somewhere; it always belongs to a command. However, a command (in 
the ARMIRS view) would not exist without an ammunition inventor}’. In the relation 
diagram (Figure 16), the circle shows the optional side while the bar shows the manda¬ 
tory side. 

2. REQUISITION & REQN LINE ITEM Objects 

The REQUISITION object consists of two COMMAND object properties, one 
multi-value object property (REQN LINE ITEM), one multi-value non-object property 
(Addressees), and five single-value non-object properties. The Document Number 
uniquely identifies a single requisition. 
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REQX LINE ITEM includes several single-value non-object properties and two 
single-value object properties (REQUISITION and AMMO INVENTORY). An in¬ 
stance of this object is a line on a requisition identified by requested NUN. This NUN 
may or may not be a NUN currently in INVENTORY. 

The relationship between REQUISITION and REQN LINE ITEM is clearly 
one-to-many. A requisition has one or more ammunition items on it, but the line items 
belong to one requisition. A parent-child relationship exists and Document Number 
becomes a foreign key in REQN LINE ITEM. This is a mandatory-mandatory re¬ 
lationship because a requisition must have at least one line item (or the ship would not 
be requisitioning anything) and a line item could not exist alone without a requisition 
header. 

Requisition Addressee is a multi-value non-object property of REQUISITION. 
Like all composite objects, more than one relation is required for representation. One 
requistion must have multiple information or action addressees. Document Number is 
therefore a key (and also a foreign key) in the REQ-ADDR relation. 

3. AMMO INVENTORY Object 

The large AMMO INVENTORY object consists of five multi-value objects, a 
single-value object (COMMAND), two multi-value properties (Mission Area and 
Stowage Location), and many properties with single values. A NUN uniquely identifies 
a particular type of ammunition in inventorj'. 

There is a one-to-many relationship between AM.MO INVENTORY and both 
the REQN LINE ITEMS and TRANSACTION objects. As a result NUN becomes a 
foreign key in the child relations. The relationship between INVENTORY and 
TRANSACTION is mandatory-mandatory because a NUN instance (a Master Stock 
Record Card) will always have at least one transaction (even if it is only the balance 
change that brought it to the ship). Of course, a balance change could not exist without 
a parent inventory. 

Two composite objects (AM.MO-MISSN and NON-LOT LOC) are also re¬ 
presented in the relational AMMO INVENTORY schema. Operational reporting (i.e., 
SORTS message) requirements require shipboard personnel to assign one or more com¬ 
bat mission areas to a NUN if the item supports an idenfifiable combat mission. A NUN 
may have more than one mission area. For example, a certain type of 5-inch gun 
projectile could be used both in anti-surface (ASUW mission area) and naval gunfire 
support (AMW mission area) roles. Assignment of these SORTS report mission areas 
is not required for all NIINs; some inventory items (c.g., small arms ammunition and 
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pyrotechnics) are not assigned to mission areas. The relational diagram shows this one^ 
to-many, mandatory-optional relationship. 

The second AMMUNITION INVENTORY composite object is NON-LOT 
LOG. This relation expresses the assignment of multiple shipboard stowage locations 
to non-SLIT NIINs. (Assigning locations to the serial and/or lot items is handled in 
other relations.) One NUN may be distributed to many ammunition lockers and maga¬ 
zines. Every NUN onboard must have a shipboard stowage location. An empty stowage 
location is not of concern for ARM IRS purposes. 

4. TRANSACTION Object 

As discussed in the preceding section, TRANSACTION is the child relation in 
the one-to-many relationship between AMMO INVENTORY and TRANSACTION. 
As a result, TlUANSACTION inherits NUN as a foreign key. 

Each transaction has multiple addressees for the ATR. A transaction cannot be 
considered complete without ATR addressees.il This composite object is also shown in 
the relational diagram. 

The relationship between TRANSACTION and the three SLIT categories is 
discussed in the next section. 

5. SERIAL and/or LOT CONTROLLED AMMO Objects 

These three objects, like their siblings TRANSACTION and REQN LINE 
ITEMS, are characterized by one (AMMO INVENTOR.Y) to many (SERIAL and,'or 
LOT CONTROLLED AMMO) relationships. In each case, the key of the parent 
(NUN) becomes a foreign key in the child relation. 

All three of these relationships with AMMO INVENTORY are mandatory- 
optional. An inventory item may be non-SLIT (having neither serial nor lot numbers). 
However, the SLIT items can only exist as a part of inventor}'; they can have no exist¬ 
ence alone. 

Each of the SLIT objects contain TRANSACTION as a multi-value object 
property, shown as three one-to-many relationships in Figure 16. Lot Number and Serial 
Number are foreign keys in this relation. For non-SLIT items, these foreign keys would 
have null values. As with the AMMO INVENTORY object, the three SLIT relations 
must always have at least one transaction (even if it is just the receipt transaction from 
an initial onload). Of course, a TRANSACTION instance could apply to a non-SLIT 
item. 


11 The rules for determining these addressees is shown in Appendix L. 
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Shipboard stowage location is a composite object (LOT-LOCATION) for am¬ 
munition controlled only by lot number. A lot may be distributed among multiple am¬ 
munition lockers and magazines. A lot number in inventory must have a shipboard 
stowage location. Again, there is no requirement to recognize empty lockers and maga¬ 
zines. 

Ammunition controlled by serial number has location as a single-value property 
because a serial number designates one ammunition round with only one location. 

B. APPLICATION DESIGN 

1. Application Scope 

As previously discussed, application of ARM IRS falls naturally into three pri¬ 
mary functions: inventory management, requisitioning, and report generation. Routine 
ARM IRS users are involved in all three processes; occasional (query-only) users include 
middle and upper management whose interaction with ARM IRS is only through the 
report generation function, often with the Gunnery Officer as intermediary. All of the 
ARM IRS processing responsibilities could be handled by one person, if necessary. Ob¬ 
viously a single-user application is appropriate. In ARM IRS, each user's view is fully 
inclusive. Of course, some restrictions on access are desirable to protect classified in¬ 
ventory data. These security mechanisms (e.g., password systems, encrypted data, etc.) 
will be provided by software outside ARM IRS or other (e.g., physical security) safe¬ 
guards. 

All three of the ARM IRS functions can be run from the same microcomputer. 
This microcomputer could be located in the Weapons Department office where many 
ships maintain their manual records. The frequencies and volumes shown in Appendix 
E make it clear that a single-user system is appropriate, even on larger ships. There is 
not even a requirement to put certain ARM IRS functions on different shipboard com¬ 
puters. All authorized ARMIRS users would have the same processing rights. 

2. Control Mechanisms 

a. Selection of Control Method 

One of the most important decisions in the design of the ARMIRS user 
interface is the selection of the transaction control method, since it determines how and 
whether the shipboard user will be able to control the application. A menu-driven system 
would minimize cognitive demands on ARMIRS users. Users would not need to learn 
any special fu,,ction keys or commands. Menu screens show th** only options available 
at the time; the users do noi have to recall specific system functions. 
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This does not mean that menus are without problems. Experienced users, 
while finding menus helpful at first, may find them tedious after they learn ARM IRS. 
Having to step through a series of menu screens can be time-consuming and frustrating 
for the sophisticated user. The use of function keys and commands is appropriate for a 
user who uses the application frequently (i.e., the Gunnery Officer in the ARMIRS 
case). 

The best solution would be to provide ARMIRS users with both menus and 
commands to control the system. A user could then choose between the two methods. 
This thesis specifies the menu system for ARMIRS. Design of a command language is 
not required. Many microcomputer DBMSs support a query language, such as the 
ANSI-standard Standard Query Language (SQL). When selecting a DBMS for 
ARMIRS implementation, quer>' language support should be an important consider¬ 
ation. 

b. Menu System 

The diagrams in Appendix G illustrate the multiple choice, multiple path 
ARMIRS menus. .As shown in Figures 17 through 20, a simple tree structure allows the 
user to make a series of cheires that take him down through lower layers of menus until 
reaching the desired destination. The top-level menu shown in Figure 17 is the ARMIRS 
main menu consisting of the basic system options. Implementation of ARMIRS should 
include designation of one keystroke to return to this menu from any^vhere in the menu 
hierarchy. 

-ARMIRS uses the "object-action" strategy of menu design. The top menu 
(Menu 0) refers to three broad object categories: (1) inventory objects (AMMO IN¬ 
VENTORY, TRANSACTION, SERIAL and,or LOT CONTROLLED AMMO), (2) 
requisition objects (REQUISITION, REQN LINE ITEM), and (3) the Na \7 activity 
object (COMMAND). When the user selects one of these options, the lower menus lead 
him to select an action (e.g., add, edit, generate) to be performed on the objects. Kroenke 
and Dolan (1988, pp. 269-270) point out that this object-action design is closer to most 
users' perspective than the aiternative action-object structure. 

If a user selects oiic of the four sub-menus shown in Figure 17, he is pre¬ 
sented with either a third-level menuTFigures 18, 19, and 20) or a form/report (if he has 
arrived at an option that does not chain to a lower menu). This menu structured is out¬ 
lined in the next section. 


33 






3. Logic and Design Materialization 

The top ARM IRS menu provides the initial user interface and provides five in¬ 
itial options: 

1. Inventor}' Management 

2. Requisition Turn-Ins 

3. Reports 

4. Ship Information!2 

5. Exit to Operating System 

Selection of these first four choices result in the menus outlined below: 

1. Inventory Management 

a. Master Stock Records 

1) Append 

2) Edit 

3) Query'Display 

b. Serial. Lot Records 

1) Append 

2) Edit 

3) Query.'Display 

c. Process Transactions 

1) Add Transaction 

2) Delete Transaction 

3) Edit Transaction 

2. Requisitions. Turn-Ins 

a. Append 

b. Edit 

c. Queiy/Display 

d. Generate Requisition/Turn-In 

1) DD-1348 Requisition 

2) DD-1348 Turn-In 

3) DAAS Requisition 

12 Selected by the user on a separate menu but functionally part of the inventor}’ management 
process. 
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4) Naval Message Requisition 

3. Generate Reports 

a. Inventory Reports 

1) Inventory Summarj' Report 

2) Allowance List Report 

3) NAR Management Report 

4) Allowance Tracking Report 

5) SORTS Message Input 

6) Ship Ammunition Inventory (Summary) 

7) Ship Anmiunition Inventory (Detailed) 

8) Maintenance Due Summary Report 

b. Transaction Reports 

1) ATR Generation 

2) ATR Log 

c. Requisition;Turn-In Reports 

1) Requisition Log 

2) Turn-In Log 

3) Outstanding Requisition Report 

4. Ship Information 

a. Edit Ship Data 

b. Display Ship Data 

The detailed logic for each of these menu options and reports is described in 
Appendix H. Ever}' menu path is described in a Structured English pseudocode that de¬ 
fines the ARM IRS system logic. Structured English borrows logical constructs from 
computer programming languages. However, the use of computer jargon is avoided and 
the specification is easier for system designers and imp'ementers to understa’^d. The use 
of Structured English in Appendix H to define the AR.MIRS menu and processing logic 
avoids many of the limitations and ambiguities of ordinary English but does not limit 
understanding only to those who know a particular computer programming language. 
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V. PHYSICAL DATABASE DESIGN 


This chapter translates the relational schema into a series of linked tables using 
PARADOX. After defining these tables, the ARMIRS reports are implemented. 

A. DBMS OVERVIEW 

Recall that objects are not stored in a database; they represent things in the user's 
work environment. There is not yet a DBMS product that actually stores objects 
(Kroenke and Dolan, 1988, pp. 256-257). In the previous chapter, the ARMIRS objects 
were transformed into relations. When the user enters a quer>’ about an object, the 
DBMS constructs the object from data in several tables. The process of creating these 
tables (in the data model of a particular DBMS software package) is called materializing 
the objects. In this chapter, the abstract ARMIRS objects and relations are implemented 
into a series of tables which a DBMS uses in running the application. 

The first step in this materialization process is selecting a particular DBMS data 
model. Three microcomputer DBMS software packages were available for ARMIRS 
object materialization: (1) INGRES for PCs (Version 5.0),13 (2) DBASE IH, and (3) 
PARADOX (Version 3.0). 

INGRES is strongly based in relational database theory; it has a pedigree that 
streches back to university research in the relational model from the early 1970s. In¬ 
stalled at several thousand sites worldwide, this DBMS has directly or indirectly influ¬ 
enced the design of several other relational systems (Date, 1987, p. iv). INGRES runs 
in may different environments (e.g., VMS, UNIX, VM/CMS, and MS-DOS), but is not 
widely used on microcomputers. The author's previous INGRES application develop¬ 
ment experience (Buzzard, et. ai, 1989) resulted in an appreciation of the power of 
INGRES but disatisfaction at the error-prone PC implementation of this mainframe- 
oriented DBMS. INGRES supports SQL and includes a visual forms editor allowing 
form definition directly on the screen. Reports are specified in lines of INGRES report 
specification code. INGRES implementation would support the ARMIRS application 
through the use of a form or example query facility (as specified in the requirements 
analysis). ' 


13 INGRES is a trademark of Relational Teclinology, Inc. 


t 


36 


DBASE III was considered for ARM IRS object materialization because it has be¬ 
come the de facto microcomputer DBMS standard. (Although advertised as "relational", 
DBASE III and IV (along with FOXBASE and other DBASE language dialects) actually 
are "relational-like" file-based systems.) As Smith (1987, p. 48) points out, the wide¬ 
spread use of DBASE makes it a good candidate for use in eventual ARMIRS imple¬ 
mentation. A significant disadvantage of DBASE is its relatively poor application 
development facility. Where INGRES uses a visual editor to design screens (forms and 
menus), DBASE requires programming lines of x,y SAY..." commands to specify the 
location of all screen elements. In contrast to the fourth generation language (4GL) used 
in INGRES application development, DBASE uses more traditional (and more difTicult) 
coding techniques. « 

PARADOX combines the full power and application development tools of INGRES 
with the widespead acceptance and PC robustness of DBASE III. In PARADOX, both 
forms and reports are specified visually, requiring no coding. A query-by-example Aicility 
is also present. PARADOX'S ease of use aided object materialization for this thesis and 
make it a prime candidate for use in future ARMIRS application development. 

B. CONSTRUCTING THE TABLES IN PARADOX 

ARMIRS objects were materialized using a multitable design. Using the previously 
defined object definitions and domain definitions, field names were assigned and field 
types were specified. Figure 21 in Appendix I shows how the AMMO INVENTORY 
object was tranformed into a table. All of the single-value non-object attributes are listed 
with the key attribute (AMMO INVENTORY.NIIN) listed first and shown with an as¬ 
terisk. The domain definitions were then used to enter the appropriate field type in the 
table definition form. The domain definitions were adjusted if required to fit the P.vR- 
ADOX syntax while preserving the previously defined ARMIRS physical constraints. 
For example, the attribute FSC consists of four numerals, which can include leading 
zeros (e.g., 0087) important for precisely formatted reports. If the PARADOX "number" 
format had been specifed in Figure 21, the FSC of 0087 would become 87 when the 
leading zeros were removed. FSC is therefore defined as type A (for alphanumeric) with 
four digits, even though non-numeral characters would never appear in an FSC. As a 
result, the leading zeros are preserved. This format change is not a disadvantage for FSC 
because compulations are not performed on this attribute. 

However, there are cases when we want to implement a mask as a validity check. 
This thesis previously defined the physical attributes of the domain definitions in Ap- 
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pendix B. During the implementation of ARM IRS into the PARADOX model, these 
constraints on valid data were also specified. In PARADOX, as in other DBMS pro¬ 
ducts, we want to supplement the information in the field description so that when the 
user enters data, the system will automatically check not only on the field type but also 
on other requirements. For example, using validity checks makes it possible to specify 
that in the two character alphanumeric COG Symbol the first character is a number and 
the second character is a capital letter. PARADOX then enforces these requirements 
whenever values are entered or changed. In PARADOX it is possible to enter validity 
checks on (1) a minimum value (e.g., the minimum FAD is "1"), (2) a maximum value 
(e.g., the maximum value on Required Delivery Date is 366), (3) a default value (e.g., if 
Activity Classification Code is not entered, the default value of "A" indicating combatant 
ships and submarines will be used), and (4) a "picture" of the exact format. These validity 
checks for the ARMIRS PARADOX tables are shown in Appendix J. 

After defining the data implementation from the objects and specifying the validity 
checks from the domain definitions, the next step is to use the relational schema to de¬ 
fine relationships between the tables. The several one-to-many relationships are defined 
by how the tables are set up. For example, the AMMO INVENTORY relation is char¬ 
acterized by seven one-to-many relations: 

1. One AMMO INVENTORY (NTIN) to many xMission Areas 

2. One AM.MO INVENTORY (NTIN) to many TRANSACTIONS 

3. One A.MMO INVENTORY (NTIN) to many Stowage Locations 

4. One AM.MO INVENTORY (NTIN) to many REQN LINE ITE.MS 

5. One A.M.MO INVENTORY (NTIN) to many LOT CONTROLLED A.M.VIO 

6. One AM.MO INVENTORY (NTIN) to many SERIAL CONTROLLED A.M.MO 

7. One A.M.MO INVENTORY (NTIN) to many SERIAL & LOT A.M.MO 

The materializations of these one-to-many relations of A.M.MO INVENTORY are 
listed in Figure 22. Each of these detail tables is shown in Figures 23 through 29. Notice 
that these detail tables (for the "many" side of the relationship) reflect the multi-value 
object attributes in AMMO INVENTORY in addition to the multi-value non-object 
properties. They were created by placing NTIN, the key of A.MMO INVENTORY, on 
the first line of the detail tables (but this time without an asterisk). The master and detail 
tables arc then linked. 

Figure 30 shows the materialization of the TRANSACTION object. Since the at¬ 
tribute ATR Addressees is a multivalue property of TRANS.^CTION, the detail table 

t 


38 





in Figure 31 was constructed using the procedure discussed above. ATR Serial Number 
is listed first (again, without an asterisk) in the detail table. Figures 32 through 42 show 
how a similar procedure was used to define and link the remaining ARM IRS relation¬ 
ships. 

C. REPORT SPECIFICATION IN PARADOX 

After defining how one table is linked to another in the multitable ARM IRS data¬ 
base, reports were implemented for these multiple tables. This process involved linking 
one table to another and designing their shared report. 

Before producing reports on this multitable database, it was necessary to decide 
which table would be the master table for each report. In a database like ARM IRS de¬ 
scribed by one-to-many relationships, the table on the "many" side of the relationship 
must be the master report table while the table on the "one" side (which had the key field 
designated with an asterisk) is the detail "lookup" table. When choosing which table to 
make the master table of these reports, the table that can be linked to the most detail 
tables is the best candidate. The ARMIRS reports implemented in PARADOX (and 
shown in the Appendix K custom report specifications) fell into three main categories; 
(1) single table reports, (2) multiple table (linked) reports, and (3) complex multiple table 
reports requiring queries. 

The easiest type of report to implement (and also the rarest in ARMIRS) was the 
single table report. For example, the Ship Ammunition Listing Report (Figure 43 in 
Appendix K) and the Allowance List Report (Figure 44) both came directly from the 
unlinked master ammunition table (M_inv). The table was first transformed into a de¬ 
fault tabular report format. Editing the field displays, editing the columns, and revising 
the headings (e.g., placing the date in the heading of each report) gave final form to the 
visual report specification. Grouping, which controls how the report information is 
sorted and divided, was then added. As shown in Figure 43, PARADOX report specifi¬ 
cations include the group bands that enclose the report table. In the Ship Ammunition 
Listing, COG is the most significant grouping and defines the principal sort. It is fol¬ 
lowed by NALC, the next inner group. 

The second type of report, the linked table report, was the most common. After 
deciding which table should be the master table, a report is designed on this table by 
linking the master table to the lookup table. This provides access to the fields in both 
tables which can be selected, edited, and placed on the report. Figure 45 is an example 
of this type of linked table report. The Allowance Tracking Report is creating by linking 
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a table (M_inv) derived from the AMMO INVENTORY object with a table (Am_bal) 
formed from the TRANSACTION object. Recall that the table "Am_bar was on the 
"many" side of the relationship and "M_inv" was on the "one" side. The two tables are 
linked together with "M_inv" as the lookup table and "Am_bar as the master table. 
After extensive editing, the group bands are added. Notice that the table is sorted by 
NALC, a field in the detail (M_inv) table. Figure 45 also illustrates use of a calculated 
field. The percentage of shipfill allowance onboard is calculated for this report and does 
not come from a table. The upper right corner of the report shows the specification for 
this calculated field. Figures 46 through 48 also illustrate the features of the linked table 
report. 

The final type of report also uses linked tables but in a slightly different way. In 
PARADOX, it is not possible to link lookup tables to other lookup tables. In the case 
of several AR.MIRS tables, it was therefore not possible to include these tables in a 
single report using the link commands. In these cases, it was necessary to compose a 
query that joined all the desired fields into a single "answer table". A report was then 
generated on f))e-t tabic. The reports in Figures 49 and 50 illustrate this type of report 
specification. I'or example, the SORTS Message Input Report (Figure 49) uses infor¬ 
mation on .micion areas (Am_mis) and balance changes (Am_bal) with inventory in¬ 
fo'The mission area and balance changes are both on the "many" side of the 
oiui-to-many relaiicnship with the inventory table (keyed by NUN). It was possible to 
In k f;u'sc tables only by querying them on the desired report fields and sending the 
output *0 a ’■a!-) ’ specifically designed for this report (Sorts_rp). The report specification 
w;is tlr-'n designed from this answer table. The NAR .Management Report in Figure 50 
is another example of this type of report. Because of the the one-to-many relationship 
between ammunition inventory [the one) and both balance changes (Am_bal) and lot 
controllled ammunition (Ani-lot) [the many], the query function was used to fill a newly 
created table from which the report was specified. 

This chapter represents the first steps in implementing the ARM IRS relational de¬ 
sign in the data model of a specific microcomputer DBMS. Obviously, there is much 
work remaining before ARM IRS can be fully implemented as a functioning prototype. 
The final chapter of this thesis suggests some promising areas for future work. 
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VI. SUGGESTIONS FOR FUTURE STUDY 


A. DEVELOPMENT OF AN EXPERT DATABASE SYSTEM 

Shipboard ammunition management, especially the preparation of requisitions and 
transaction reports, is a very rule-intensive process. Expertise in ATR and ammuniton 
requisition drafting comes only after hours of work using many required references. 
Gradually, the Gunnery OIBcer becomes familiar with the procedures used to draft these 
documents. By the time the user has become familiar with the intricacies of this function, 
the new expert is often transferred to another division or ship. After this loss of corpo¬ 
rate knowledge, the learning process begins again with another olTicer. Unless the 
Weapons Department is fortunate enough to have a former Gunnerj'.'Ordnance OlTicer 
available to share his expertise, preparation of ATRs and requisitions will initially be 
inelfecient and subject to errors. A computer-based system combining the ARM IRS 
database developed in this thesis and an expert system incorporating the rules from fleet 
anununition management instructions promises to be a valuable aid in ATR/requisition 
processing and Gunnery- Oflicer training. 

Integrating the ARM IRS database and the fleet ammunition management in¬ 
structions into an expert database system is the most promising suggested area for fur¬ 
ther work. Other researchers in this field (Kamel and Lekey, 1990) have demonstrated 
the value and feasibility of such an approach to create a loosely coupled system in which 
the database's integrity is maintained while an expert system uses the data, its own rule 
base, and user input. The ARM IRS database could still be used as a stand-alone inter¬ 
active system for ammunition management. As a component in the expert database 
system, it would provide data to an Ammunition Management Expert System. For ex¬ 
ample, using ARM IRS information about the ship and the ammunition involved in a 
transaction, the expert database system would use its rules to create the ATR header, 
aiding in classification and addressing decisions essential to transaction report drafting. 
Appendix L describes the dialogue and rule base components of just such an expert da¬ 
tabase system for creating the ATR header. 

As shown in Appendix L, the system dialogue consists of a series of questions pre¬ 
sented to the user as multiple choice menus and data entry lines. When the expert da¬ 
tabase system is selected, the user is prompted for answers to these questions. 
Information from the COMMAND and AM.MO INVENTORY (through TRAN'S- 


41 






ACTION) objects is extracted from the database and applied to the addressing and 
classification rules. The resulting decisions are displayed to the user and passed to the 
TRANSACTION object in the ARMIRS database from which an ATR can be gener¬ 
ated. 

The rule base, also shown in Appendix L, is a series of 20 rules in the IF-THEN 
format used by Hayes-Roth (1985, pp. 930-934). This rule base performs logical deci¬ 
sions using input from the ARMIRS database to help make the classification and ad¬ 
dressing decisions used in the ATR header. 

Use of an expert system shell (with an expanded set of IF-THEN rules) working 
together with the ARMIRS database offers the promise of storing ammunition man¬ 
agement e.xpertise and making this rule-based knowledge available to shipboard person¬ 
nel. The development of an expert database system is the most promising area for future 
work. 


OTHER SUGGESTIONS FOR FUTURE WORK 


This thesis represents only an initial iteration of system development for a prototype 
shipboard ammunition management system. In addition to work on the expert database 
system discussed above, the following projects are suggested: 


1. Fully implement the ARMIRS design (including security and backup components 
not designed in this thesis) with a relational microcomputer DBMS software pack¬ 
age. 

2. Using the testing theories of software engineering, develop a test and evaluation 
plan to specify white- and black-box testing strategies for ARMIRS, including the 
development of sample data sets. 

3. Using a commercially available prototype;demo software product with "screen- 
grabber" capability (i.e., PROTEUS, etc.), produce a "workalike prototype", prod¬ 
uct demonstration, or ARMIRS tutorial. None of these would require full DBMS 
implementation (item 1 above) as a prerequisite and would be an excellent vehicle 
for user input for the next design iteration. 

4. Select an ARMIRS test ship, use a functioning prototype (from item 1 above) to 
run ARMIRS in parallel with the manual system, solicit feedback, and report les¬ 
sons learned. 


5. Write a ARMIRS user's manual that would completely guide the ammunition 
management (or computer) novice through system use. 

6. Investigate the feasibility of incorporating ARMIRS into the Shipboard Non- 
Tactical ADP System (SNAP) now common on U. S. Navy ships. 


7. Analyze the issues in directly connecting ships to SPCC's Navw-wide CAIMS da¬ 
tabase or the NOMIS system at weapons stations. What changes would be re¬ 
quired of the ARMIRS design? How could ARMIRS interface with the shore 
establishment? 


42 





8. Develop a bar code scanning module to work with the ARMIRS database appli¬ 
cation aboard ship. The system should be compatible with the Fleet Optical Scan¬ 
ning Ammunition Marking System (FOSAMS) used in shore-based ammuntion 
management systems. 

9. Enhance ARMIRS functionality by proving for efficient bulk data initial entry. 

10. Use commercial form-generation software packages to reproduce DD Form 1348 
and other forms in a manner consistent with ARMIRS database design but not 
limited to a specific DBMS implementation (i.e., DBASE, PARADOX, etc.). 




APPENDIX A. OBJECT DIAGRAMS 
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REQN LINE ITEM 


*NIIN 

Quantity 

Project Code 

Media Status Code 

Signal Code 

Demand Code 

Advice Code 

Fund Code 

Urgency of Need 

Required Delivery Date 

Status 

Classification 
Priority Code 


REQUISITION 


AMMO INVENTORY 


Figure 2. REQN LINE ITEM Object 








AMMO INVENTORY 


Figure 3. 


♦»NIIN 

NALC 

FSC 

Short Title 
COG Symbol 
Unit Price 
Sonobouy Channel 
Shipflll Allowance 
Warning Level 
Mission Allowance 
Annual Training Allowance 
Unit of Issue 
CC Hazmat Class 
NHEEW 

DOT Hazmat Code 
MCC 

Remarks 
Quantity on Hand 
Stowage Location MV 
Mission Area MV 


COMMAND 


REQN LINE ITEM 


MV 


TRANSACTION 


MV 


LOT-CONTROLLED AMMO 


MV 


SERIAL-CONTROLLED AMMO 


MV 


SERIAL & LOT-CONTROLLED AMMO MV 


AMMO INVENTORY Object 












LOT-CONTROLLED AMMO 


*Lot Number 
Stowage Location MV 


AMMO INVENTORY 


TRANSACTION MV 



SERIAL-CONTROLLED AMMO 


♦♦Serial Number 
Maint. Due Date 
Type of Maint. Due Code 
Condition 
Stowage Location 


AMMO INVENTORY 


TRANSACTION MV 



SERIAL & LOT-CONTROLLED AMMO 



Figure 4. LOT and/or SERIAL AMMO Objects 























TRANSACTION 


♦♦ATR Serial Number 

♦♦ATR Line Number 

Document Number 

Jul<‘=\n Date 

Old Balance 

Quantity issued 

Quantity Received 

Receipt Code 

issue Code 

Loss Code 

Extended Price 

Training Allowance to Charge 

Quantity Experied 

Transaction Type 

Cons1gnee“Consignor Die 

Balance Serviceable 

Balance Unserviceable 

Training Allowance Unexpended 

Quantity Due In 

Condition Code 

Revised Condition Code 

Remarks 

Referenced ATR 

NAR Serial 

ATR Class 

ATR Declass 

ATR Addressees MV 



LOT & SERIAL-CONTROLLED AMMO 












APPENDIX B. OBJECT SPECIFICATIONS 


A. OBJECT DEFINITIONS 

1. COMMAND Object 

• *UIC; Unit-identification-codes 

• Name; Navy-comniand-names 

• Hull Number; Hull-numbers 

• Service Designation Code; Service-designation-codes 

• Location; Mailing-addresses 

• FAD; Force-activity-designators 

• Fleet; Logistics-commanders 

• Activity Classification Code; Activity-classification-codes 

• REQUISITION MV; REQUISITION object 

• AMMO INVENTORY MV; AMMO INVENTORY object 

2. REQUISITION Object 

• ^Document Number; Document-numbers 

• Document Identifier; Document-identifiers 

• Classification; Security-classifications 

• Reqn Declas; Declas-dates 

• Remarks; Remarks 

• Addressees MV; Na\ 7 -command-names 

• COMMAND; COMMAND object 

• COMMAND; COMMAND object SUBSET [UIC, Name, Location] 14 

• REQN LINE ITEM MV; REQN LINE ITEM object 

3. REQN LINE ITEM Object 

• ’"NUN; National-item-identification-numbers 

• Quantity; Reqn-qty 

14 Note that the COMMAND object occurs twice in the REQUISITION Object. The first 
occurence is for the ship sending the requisition (the ship of interest for AR.MIRS purposes). The 
second occurence is for the sliip or weapons station filling the requisition. In the latter case, only 
a subset of the CO.M.MAND object properties is needed for the requisition. 


51 







Project Code; Project-codes 

Media Status Code; Media-status-codes 

Signal Code; Signal-codes 

Demand Code; Demand-codes 

Advice Code; Advice-codes 

Fund Code; Fund-codes 

Urgency of Need; Need-urgencies 

Required Delivery Date; Required-delivery-dates 

Status; Reqn-status 

Classification; Security-classifications 

Priority Code; Priority-codes 

REQUISITION; REQUISITION object 

AMMO INVENTORY; AMMO INVENTORY object 

4. AMMO INVENTORY Object 
*NIIN; National-item-identification-numbers 
NALC; Navy-ammunition-logistics-codes 
FSC; Federal-supply-codes 
Short Title; Nomenclature 
COG Symbol; Material-cognizance-symbols 
Unit Price; Money 

Sonobouy Channel; Sonobouy-channels 

Shipfill Allowance; Shipfill-allowances 

Mission Allowance; Mission-allowances 

Annual Training Allowance; NCEA-training-allowances 

Unit of Issue; Units-of-issue 

Stowage Location MV; Shipboard-magazines-and-lockers 
CG Hazmat. Class; USCG-hazardous-material-classifications 
Activity Classification Code; Activity-classification-codes 
NHEEW; Net-explosive-weights 

DOT Hazmat, Code; DOT-hazardous-material-classifications 
MCC; Material-control-codes 
Remarks; Remarks 

t 
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• Warning Level; Low-stock-warning-levels 

• Quantity on Hand; Onboard-totals 

• Mission Area MV; Mission-areas 

• REQN LINE ITEM MV; REQN LINE ITEM object SUBSET [NALC, NUN, 
Quantity]; REQUISITION object SUBSET [Document Number] 

• COMMAND; COMMAND object SUBSET [UIC, Name, Hull Number] 

• TRANSACTION MV; TRANSACTION object 

• LOT CONTROLLED AMMO MV; LOT CONTROLLED AMMO object 

• SERIAL CONTROLLED AMMO MV; SERIAL CONTROLLED AMMO object 

• SERIAL & LOT CONTROLLED AMMO MV; SERIAL & LOT CON¬ 
TROLLED AMMO object 

5. LOT CONTROLLED AMMO Object 

• ’•'Lot-Number; Lot-numbers 

• Stowage Location MV; Shipboard-magazines-and-lockers 

• AMMO INVENTORY; AMMO INVENTORY object 

• TRANSACTION MV; TRANSACTION object 

6. SERIAL CONTROLLED AMMO Object 

• "'Serial Number; Serial-numbers 

• Maint. Due Date; Maint-due-dates 

• Type of Maint. Due Code; Maint-due-types 

• Condition; Conditions 

• Stowage Location; Shipboard-magazines-and-lockers 

• AMMO INVENTORY; AMMO INVENTORY object 

• TICANSACTION MV; TRANSACTION object 

7. SERIAL & LOT CONTROLLED AMMO Object 

• ’^'Lot Number; Lot-numbers 

• ^Serial Number; Serial-numbers 

• Maint. Due Date; Maint-due-dates 

• Type of Maint. Due Code; Maint-due-types 

• Condition; Conditions 

• Stowage Location; Shipboard-magazines-and-lockers 

• AMMO INVENTORY; AMMO INVENTORY object 
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• TRANSACTION MV; TRANSACTION object 


8. TRANSACTION Object 

• *ATR Serial Number; ATR-serial-numbers 

• *ATR Line Number; ATR-line-numbers 

• Document Number; Document-numbers 

• Julian Date; Julian-dates 

• Old Balance; Old-balances 

• Quantity Issued; Issued-qty 

• Quantity Received; Received-qty 

• Receipt Code; Receipt-codes 

• Issue Code; Issue-codes 

• Loss Code; Loss-codes 

• Extended Price; Money 

• Training Allowance to Charge; Unit-idcntification-codes 

• Quantity Expended; Expended-qty 

• Transaction Type; Transaction-types 

• Consignee or Consignor LTC; Unit-identification-codes 

• Balance Serviceable; Serviceable-balances 

• Balance Unserviceable; Unserviceable-balances 

• Training Allowance Unexpended; NCEA-remaining 

• Quantity Due In; Due-in-qty 

• Condition Code; Condition-codes 

• Revised Condition Code; Condition-codes 

• Remarks; Remarks 

• Referenced ATR; ATR-sorial-numbers 

• NAR serial; NAR-serial-numbers 

• ATR Class; Security-classifications 

• ATR Declas; Declas-dates 

• ATR Addressees MV; Navw-command-names 

• AMMO INVENTORY; AMMO INVENTORY object 

• LOT CONTROLLED AMMO; LOT CONTROLLED AMMO object, or 

• SERIAL CONTROLLED AMMO; SERIAL CONTROLLED AMMO object, or 
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• SERIAL & LOT CONTROLLED AMMO; SERIAL & LOT CONTROLLED 
AMMO object 

B. DOMAIN DEFINITIONS 

(1} Activiiy-dassification-codes 

• Alphabetic 1 

• Code (from SPCCINST, 1988, p. 8-5-Dl) indicating the intended use of ammuni¬ 
tion stocks carried by a command. 

• ARM IRS default is [A], indicating use on combatant ships and submarines. 

(2) Advice-codes 

• Text 2 

• Code from requisition originators to initial processing points to provide coded in¬ 
structions to supply sources. 

(3) ATR-line-inonbers 

• Numeric 2 

• Indicate position of a transaction line item on an Ammunition Transaction Report. 

ATR-serial-nmnbers 

• Numeric 3 

• Serial number locally assigned to an Ammunition Transaction Report. Restarts at 
001 after reaching 999. 

(5} Condiiions 

• Text 1 

• ARM IRS code indicating ammunition condition either as serviceable [S] or un¬ 
serviceable (L’j. 

(6) Condition-codes 

• Alphabetic 1 

• Code (from SPCCINST 8010.12D, 1988, p. 1-2-CI) for classifying ammunition in 
terms of readiness for issue and use, or to identify action undenvay to change the 
status of the material. 

• ARM IRS default is [A], indicating fully serviceable ammunition. 

(7) Declas-daics 

• Text 7, mask NNAAAXN 

• Where NN is numeric, A.AA is alphabetic [JAN...DEC], and NN is numeric. 

• The date a classified message is to be declassified (e.g., 29APR59). 
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(8) Demand‘Codes 


• Text 1 

• Indicates whether the demand for a requisitioned item is recurring [R] (ARMIRS 
default) or non-recurring [N]. 

(9) Document-identifiers 

• Text 3 

• Code (from SPCCINST 8010.12D, 1988, p. 8-2-6) to indicate the purpose oY doc¬ 
ument (i.e., requisition, cancellation, follow-up, etc.) 

(10) Document-numbers 

• Text 14, mask TXNNNNNNNNNNNN, 

• Where TNNNNN is the LTC, NNNN is the julian date, NNNN is serial number. 

• Identifies a requisition or turn-in document. 

(11) DOT-hazardous-material-classifications 

• Text 2 

• Code assigned by the Department of Transportation to indicate the type of hazard 
involved when shipping ammunition. 

(12) Due-in-qty 

• Numeric 5 

• Requisitioned quantity still outstanding. Represents the unfilled balance of a 
requistion. 

(18) Expended-qty 

• Numeric 5 

• Quantity of ammunition reduced from inventory by means other than transfer or 
condition code change. 

(14) Federal-supply-codes 

• Numeric 4 

• Code used with NUN or NALC for ammunition identification. 

(15) Force-activity-designators 

• Numeric 1 

• Number [1-5] assigned to a command from NAVSUP Pub 485, sections 3045-3049 
to reflect operational readiness and used (with Urgency of Need Code) to assign a 
requisition priority. 
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(16) Fund'Codes 

• Text 2, mask T6, 

• Where T is text [cither 2 or Y) and 6 is the numeral six. 

• Code used to cite accounting data on requisitions. 

• Fleet units use fund code Y6 (ARMIRS default) and shore units use fund code 26. 

(17) Hull-numbers 

• Text 8 

• Hull number assigned to a commissioned naval vessel (e.g., FF1071, SSN685). 

(18) Issue-codes 

• Text 6 

• Code (from SPCCINST 8010.12D, 1988, p. 8-5-Hl) indicating how ammunition 
was issued from inventory to another command. 

(19) Issued-qiy 

• Numeric 5 

• Quantity transferred from a command resulting in an inventor}’ quantity decrease. 

(20) Julian-dates 

• Numeric 4, mask YDDD, 

• Where Y is the last digit of the year [0-9] and DDD is the number assigned to the 
day [001-366]. 

• Date of an event or document consisting of the units digit of the year and a three 
digit expression of the numeric equivalent of the day of the year (e.g., 9004 is 04 
JAN 1989). 

(21) Logistics-commanders 

• Alphabetic 4 

• The Fleet CINC having authority over a unit's ammunition logistics reporting. 

• Commands under CINCPACFLT use [PAC] while units under CINCLANTFLT 
use [LANT]. 

(22) Loss-codes 

• Alphabetic 5 

• Code (from SPCCINST 8010.12D, 1988, p. 8-5-11) indicating how ammunition was 
lost from inventory (i.e., through physical count, by accounting error, by theft, etc.) 
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(IS) Lohnumbers 


• Text 16 

• A number assigned at the time of manufacture to a group of ammunition rounds, 
each component of which is produced by one manufacturer under uniform condi¬ 
tions and which is expected to perform in a uniform way. 

(24) Low-siock-warning-levels 

• Numeric 2 [.01-.99] 

• Stock level (expressed as a percentage of allowance) where the user is warned of a 
low stock condition. 

(25) Mailing-address 

• Tc.xt 30 

• Location of an amnumtion transaction or a requested deliverj' location (e.g., 
CONCORD CA or PEARL HARBOR HI). 

{26j Maint-due-daies 

• Text 3, mask MYY, 

• Where M is the month (1-9,0,N,D] and YY is the last two digits of the year. 

• The month and year (e.g., N'90 is NOV 1990) of the next scheduled maintenance 
on items with serial numbers serial numbers. 

(27) Maint-due-iypes 

• Alphabetic 1 

• Indicates the tvpe of periodic maintenance required for torpedoes and air-launched 
missiles from S'PCCINST 8010.12D (1988, p.8-5-Bl). 

(2S) Material-cognizance-symbols 

• Text 2, mask NA, 

• Where X is a number and A is a letter. 

• Indicates the Inventor}- Control Point, ofiice, or agency which exercises supply 
management responsibility for an item. 

• Allowed values for conventional ammunition are OT, 2D, 2E, 2T, 4E, 4T, 6T, 8E, 
8S, 8T, and 8U. 

(29) Material-control-codes 

• Alphabetic I 

• Code assigned by the Inventor}' Manager to indicate to field activities that special 
reporting or control requirements may be necessary. Indicates a serial/lot tracked 
item. 
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(SO) Media-status-codes 


• Text 1 

• Code used in requisitions to indicate the type of supply status required and the 
method by which it is to be furnished. 

(SI) Mission-allowances 

• Numeric 5 

• The quantity of ammunition above and beyond shipfill allowance for use on a 
specific mission. 

(32) M ission-areas'^ 5 

• Alphabetic 4 

• Combat mission area(s) associated with an ammunition type. 

• Allowed values are (ASUW, ASW, AAW, AMW (for amphibious warfare), and 
MIW (for mine warfare)] as described in NWP-7. 

• Used in SORTS readiness repoit input to the Operations Department. 

(33) Money 

• Text 13, mask NN,NNN,NNN.NN 

• Where X is numeric and a leading dollar sign is not used. 

• Used for prices on turn-in documents. 

(34) NA R-serial-numbers 

• Numeric 5, mask YYNNN, 

• Where YY indicates the year and NNN indicates the serial number. 

• Assigned to Notices of Ammunition Reclassification. 

( 35 ) National-item-identification-numbers 

• Text 9 

• A stock number assigned by the Defense Logistics Services Center to each item in 
the Federal Cataloging Program. 

( 36) Navy-ammunition-logistics-codes 

• Text 4 

• Code assigned to ammunition groups by SPCC. 


15 LCDR Carl A. Carpenter, L’SN contributed useful insights on the Operations Department 
view of ammunition inventory data. 


l. 
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(11) Navy-command-names 

• Text 30 

• Name of a command as listed in the Plain Language Address Director}'. 

(38) NCEA-remaining 

• Numeric 5 

• The quantity of ammunition with a training allowance available for expenditure in 
the current fiscal year. 

(39) NCEA-iraining-allowances 

• Numeric 5 

• The quantity of a particular ammunition item authorized for expenditure in a fiscal 
year for training. Promulgated in the 30000 series NAVSEA Shipfill Allowance 
List. 


(40) Need-urgencies 

• Alphabetic 1 

• Letter code [A, B, or C] designating the impact on mission readiness if a requisition 
is not received by the lequired delivery date. Used with Force Activity Designator 
to give a requisition's priority. 

(41) Net-explosive-weighis 

• Text 10 

• Total weight of explosive components of a device. Expressed in whole numbers 
with the units (i.e., 20 LBS, 30 KG). 

( 42 ) Nomenclaiure 

• Text 20 

• Short te.xt description of amm.unition consisting of noun name and MK/MOD 
from NAVSEA TWOlO-AA-ORD-010. 

( 43 ) Old-balances 

• Numeric 5 

• The inventor}' balance prior to a transaction or the balance brought forward to a 
new inventor}' record. 

(44) Onboard-totals 

• Numeric 5 

• The total quantity onboard for a particular NUN, regardless of condition. 
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(45) Priority-codes 

• Numeric 2 

• Code expressing the relationship between COMMAND.FAD and REQN LINE 
ITEM.Urgency of Need to represent the priority assigned to a requisition. 

(46) Project-codes 

• Text 3 

• Code assigned to a specific project by DoD. Used on requisitions for recognition 
throughout the distribution system. 

(47) Receipt-codes 

• Text 6 

• Code (from SPCCINST 8010.12D, 1988, p. 8-5-Gl) indicating how the material 
was added to the command's inventory. 

(48) Received-qty 

• Numeric 5 

• Quantity of ammunition received and added to the inventor)'. 

(49) Remarks 

• Te.xt 30 

• Text used for adding comments and references where desired. 

^50) Reqn-qty 

• Numeric 5 

• Quantity of an ammunition item requisitioned. 

''51) Reqn-status 

• Alphabetic 1, mask [U,P,F,C] 

• ARM IRS code indicating the status of a requisition line item where [U| = unfilled, 
[P] = partial, [F] = filled, and [C] = cancelled. 

(52) Required-delivery-dates 

• Text 3 

• Three-digit Julian date [1-306] indicating the date required for receipt of requisi¬ 
tioned ammunition. 

(53) Security-classifications 

• Alphabetic 1 
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• Code indicating security classification of a requisition, transaction report, or other 
message (or part of any message). 

• Unclassified is indicated [U] (ARMIRS default) and Confidential is indicated by 
[C]. Secret and Top Secret are not used for conventional ammunition messages. 

(54) Serial-numbers 

• Text 16 

• An identification number given to an single ammunition round. 

(55) Service-designaiion-codes 

• Text 1 

• Code designating a military service or part of one of the uniformed services. 

(56) Serviceable-balances 

• Numeric 5 

• Quantity of ammunition available for use. 

(57) Shipboard-magazines-and-lockers 

• Text 12 

• Compartment number of ammunition storage location. 

(58) Shipjill-allowances 

• Numeric 5 

• Ammunition quantity computed for allowance requirements during provisioning. 

(59) Signal-codes 

• Te.xt I 

• Code on requisition indicating consignee (ship to) and the activity to receive the 
bill (bill to). 

(60) Sonobouy-channels 

• Numeric 2 

• Indicates the preset channel on certain sonobouys. 

(61) Transaciion-iype 

• Text 2 

• Code (from SPCCINST 8010.;2D, 1988, p. 8-5-Fl) indicating the type of trans¬ 
action (i.e., receipt, issue, adjustment, inventory loss, etc.). 
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(62) Vnit-identificat ion-codes 

• Numeric 5 

• Code which identifies a command. 

(63) Units-of-issue 

• Alphabetic 2 

• Abbreviation representing a quantity and serving as a unit of measurement when 
issuing ammunition (e.g., BX, EA, CA). 

(64) Unserviceable-balances 

• Numeric 5 

• Quantity of ammunition unavailable for use due to condition code. 

( 65) US CG-hazardous-material-classifications 

• Text 4 

• Classification codes of hazardous munitions as determined by the U.S. Coast 
Guard and found in N'AVSEA OP 2165, Vol. 2. This code determines how ammu¬ 
nition is loaded aboard ship. 
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APPENDIX C. DATAFLOW ANALYSIS 
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Figure 8. Process 1 (Manage Inventory) Diagram 
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Figure 9. Process 2 (Generate Requisitions/Turn-Ins) Diagram 
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Figure 10. Process .3 (Generate Reports) Diagram 
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Figure 12. COMMAND Information Form 
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Figure 13 
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REQUISITION INFORMATION 
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APPENDIX E. FUNCTIONAL COMPONENT DESCRIPTIONS 


A. MANAGE INVENTORY APPLICATION 

1. Manage Inventor}' Update Mechanisms 
a. Add New COMMAND Data 

16 

• Input 

• UIC, Name, Hull Number, Fleet, Service Code, Activity Classification Code, 
and Location (required only for requisitions) of the ARMIRS ship. 

■ UIC, Name, Hull Number (N,'A for shore commands). Service Code, Activity 
Classification Code, and Location (required only for requisitions or turn-ins) of 
the other unit, if any, involved in an inventor}' action. 

• Output 

■ New COM.VI AND object instance 

■ Confirmation message on screen 

• Processing Notes 

■ There may not be information on another command to enter if the system is 
newly installed and has not yet been used for a transaction involving another 
command. 

■ The location and fleet of the ARMIRS ship may change, but the other ship in¬ 
formation is static. 

■ There is not always another unit involved in a reportable action. For example, 
the system does not make any use of information on another command for a 
transaction involving an ammunition expenditure (e.g., loss, firing, etc). 

• Volume 17 

■ Once for ARVIIRS ship static information. 

■ 14 times per year for information on the participating unit. 

• Frequency 

■ .Monthly (as information changes) 


16 Functionally part of the inventory management process but selected by the user from a 
separate menu. 

17 Volumes and frequencies are (maximum) estimates for Knox class frigates, a typical smaller 
combatant sliip. Values for other platforms may vaiy. Volumes and frequencies are higlily de¬ 
pendent on a sliip's operating schedule. 
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b. Edit COMMAND Data 


• Input 

■ Correction information on own ship or other unit as provided by Gunnery Of¬ 
ficer based on information tied to major ship movements. 

• Output 

• Modified COMMAND object instance(s) 

• Confirmation message on screen 

• Processing Notes 

“ This function changes basic command and location data to update the COM¬ 
MAND object. 

• There are no multiple presentations of this screen for the user to page through. 
New information is simply typed over the outdated information on the form 
(Figure 12) and the update is processed. 

■ A history of CO.MMAND Information Forms is not required. Only one form 
is required and that form is updated as changes occur. 

• Volume 

■ 14 times per year. 

• Frequency 

■ Monthly (as information changes) 

c. Add a New Stock Record 

• Input 

■ Ammunition received onboard for which a stock record does not already exist. 

■ NALC, FSC, NTIN, N"ire, COG, MCC, and Sonobouy Channel from the 
markings on the ammun, on, markings on ihe shipping container, or from the 
DD Form 1348 which accompanies the rnioaded ammunition. 

■ Shipfill and NCEA Allowances from allowance lists held by the ship. 

■ Unit Price, N'HEEW, DOT and USCG Hazmat codes from NAVSEA publica¬ 
tion TWO lO-AA-ORD-10 held onboard. 

■ Shipboard location (for non-SLIT-controlled it.ms) from the Gunnery Officer 
or Chief Gunner's Mate in accordance with the ship's lor ling plan. 

■ Defined low stock level as determined by the Weapons Olficei. 

■ Combat mission area(s) supported by this item from the Weapons Officer (after 
liason with the Operations Officer). 

• Output 

■ New AM.MO INVENTORY object instance 

■ Confirmation message on screen 
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• Processing Notes 

■ User may not have all the available information at the time of inital entrj’ (e.g., 
receipt of a new N'ALC for which Operations and Weapons Department Heads 
have not defined the mission area(s) supported) and later editing may be re¬ 
quired when all the information has been collected. 

« Equivalent action in the manual system would be to discover that a Master 
Stock Record Card does not exist for a newly acquired NUN, obtain a blank 
card, complete the header information, and file the card. 

■ This action completes the top section of the form shown in Figure 13. 

• Volume 

■ Six times per year 

• Frequency 

■ Bimonthly 

rf. Edit Descriptive Data 

• Input 

■ Correction information from revisions to: (1) allowance lists, (2) the loadine 
plan, (3) NAVSEA Publication TWO lO-AA-ORD-010 ("The NALC/NTIN 
Book"), and (4) the Weapons OlTicer's determination as to low stock warning 
levels and mission area(s) supported. 

■ AMMO INVENTORY object instance 

• Output 

■ Modi led AMMO INVENTORY object instance 

■ Confirmation message on screen 

• Processing Notes 

• This function modifies the general, descriptive (not quantity) information on a 
particular NALC and NUN. 

■ Equivalent in the manual system to making corrections to the non-transaction 
fields on the Master Stock Record Card. 

■ Retrieved from the database (most commonly by NUN) in a query and edit 
mode when changes are necessary. Requires NUN (or other property in the top 
section of Figure 13) for retrieval. 

• Volume 

■ Four times per year 

• Frequency 

■ Quarterly 
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<?. Add (Post) a Transaction 

• Input 

■ AMMO INVENTORY object 

• Balance change information shown on the "Stock History" and "Transaction 
Reporting" sections of Figure 13 entered by the user. 

■ ATR addressees from an expert database system (see Chapter VI) or from user 
input. 

• Output 

■ Updated A.MMO INVENTORY object (new total posted) 

■ New TRANSACTION object instance 

■ Updated SERIAL and/or LOT CONTROLLED AMMO object instance (if 
applicable) 

■ Confirmation message on screen 

• Processing Notes 

■ Each change in ammunition inventory, regardless of the reason, requires a new 
TRANSACTION instance. 

■ Manual equivalent to this operation is to make a single line entry on the trans¬ 
action histoiy section of the Master Stock Record Card in preparation for 
drafting an ATR. 

■ If a serial number or lot number exists for a NUN, the Serial/Lot Record is also 
updated. 

■ The total quantity on hand, regardless of condition, is update to the AMMO 
INVENTORY (NUN) record when the transaction's posted (automatically in 
ARM IRS). 

■ User must assign the next sequential ATR serial number (from the ATR Log) 
to each instance. 

■ Document Number is required only for receipt and turn-in transactions. It is 
obtained from the DD Form 1348 accompannnying the ammunition (receipt) 
or assigned by the user (turn-in). 

• Volume 

■ 60 per year, with most of the transactions occuring in two or three major 
onloads offloads per year. 

■ Peak activity before or after deployments and overhauls. 

• Frequency 

• Weekly 
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/. Edit Transaction Data 

• Input 

■ TRANSACTION object instance 

■ ATR Serial Number and Line Number from the user 

■ Revised transaction data from the user 

• Output 

• Modified TRANSACTION object instance 

■ Updated SERIAL and/or LOT CONTROLLED AMMO object instance (if 
applicable) 

■ Confirmation message on screen 

• Processing Notes 

■ Used to correct typographical errors on a TRANSACTION instance already 
added to the database. 

■ To change the meaning of a TRANSACTION instance on a transaction for 
which an ATR has already been transmitted, a new instance (see preceding 
section) must be created and a new ATR generated. 

■ Manual equivalent to this action is correction (erasure) of a field on a single line 
in the transaction historj' section of the Master Stock Record Card. 

• Volume 

■ 16 times per year 

• Frequency 

■ Monthly 

g. Add a New SerialjLot Record 

• Input 

■ Serial Number and/or Lot Number from markings on the ammunition, on the 
container, or on the DD Form 1348 accompanying the ammunition. 

■ .Viaintenance Date, Maintenance Type, and Condition Code from the mainte¬ 
nance records accompanying the item. 

■ Location for shipboard stowage from the Gunnery' Officer or G.MC in accord¬ 
ance with the ordnance loading plan. 

• Output 

- New SERIAL/LOT CONTROLLED AMMO instance 

■ Confirmation message on screen 

• Processing Notes 

■ Entered on the center section of the Serial/Lot Information Form (Figure 14). 

L 
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■ Requires a "parent" AMMO INVENTORY instance (with the NUN* of the 
prospective "child" lot or serial controlled item) already in the database before 
this process can occur. 

• Volume 

■ 30 times per year, usually grouped into 4 major ofiload or onloads 

• Frequency 

• Quarterly 

h. Edit Serial!Lot Information 

• Input 

■ Correction to descriptive information on a lot or serial ordnance item, including 
change to Maintenance Due Date, Maintenance Due Type, or Location. 

• Output 

. Modified LOT and,'or SERIAL CONTROLLED AMMO instance 

• Processing Notes 

■ Condition Code (and Quantity) are not revised in this process. Those actions 
require transaction reports and are accomplished through TRANSACTION. 

■ This function accomplishes the same result for SLIT-controlled ammunition as 
that performed by "AMMO INVENTORY: Edit Descriptive Data" (Section 
A-l-d of this Appendix) for non-SLIT ammunition. 

■ Equivalent action in the manual system is correcting non-transaction informa¬ 
tion on a Serial.'Location Card or a Lot,'Location Card. 

■ Records are retrieved from the database in a qucr\'-by-forms edit mode using the 
Serial Number or Lot Number as the basis for retrieval. 

• Volume 

■ Six per year 

• Frequency 

■ Bimonthly 

2. Manage Inventory Display Mechanisms 
a. COMMAND Information Display 

• Output Description 

■ Form showing LTC, Hull Number (ships only). Command Name, Location, 
Activity Classification Code, Fleet, and Service Code for the host (ARMIRS) 
ship and the other command involved in a transaction or requisition (See Figure 
12 ). 

• Source Data 

■ COMMAND object 
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Processing Notes 

■ Since there is only one form representing both current instances of the COM¬ 
MAND object, displaying the form is activated by a menu selection and not a 
query-by-forms action (on UIC, etc.). 

■ The form is displayed prior to generating a requisition or transaction when the 
user finds the COMMAND data outdated. 

Volume 

■ 35 times per year 

Frequency 

• Biweekly 

b. Stock Record Display 

Output Description 

■ Form showing descriptive data on a NUN as shown in Figure 13. 

Source Data 

- AM.MO INVENTORY object 

■ AMMO INVENTORY property (commonly NUN) keyed by user and used as 
the basis for record retrieval. 

Processing Notes 

■ If NUN (the key attribute in A.M.MO INVENTORY) is used in the display 
query-by-forms mode, then only one screen will be available for display. If the 
user has only the NALC or (worse) only the COG then it will be necessary to 
page through a number of screens until the desired object instance is found. 

■ Equivalent in the manual system to looking up a .Master Stock Record Card in 
a set of cards filed by NALC and then by NUN. 

Volume 

■ 40 per year 

Frequency 

■ Biweekly 


c. Stock History Display 
Output Description 

■ Form showing the stock and transaction history for a NUN. Information on 
this form (Figure 13) includes Balance, Condition Codes, Quantity, New Bal¬ 
ance and other information shown on the ATR(s) for this NUN. 

Source Data 

• TRANSACTION object 

■ AM.MO INVENTORY object 




• NUN (or other property to use in retrieval) from user 
Processing Notes 

■ See Stock Record Display 
Volume 

• 60 per year 
Frequency 

. Weekly 

d. Display Lot/Serial Record 
Output Description 

■ Form showing descriptive data on a serial or lot controlled item as shown in 
Figure 14. 

Input 

- SERIAL CONTROLLED AMMO object, or 

- LOT CONTROLLED AMMO object, or 

• SERIAL & LOT CONTROLLED AMMO object 

■ Serial Number or Lot Number entered by the user and used as the basis for re¬ 
cord retrieval. 

Processing Notes 

■ Equivalent in the manual system to looking up a Serial, Location Record Card 
or a Lot. Location Record Card. 

■ If Serial Number or Lot Number (the key attributes in their respective objects) 
are used in the display querj’-by-forms mode, then only one screen will be re¬ 
trieved. However, if the user knows only a non-key attribute (e.g., NALC, COG, 
Location) then it will be necessary to page through a number of screens until 
the desired instance is found. 

Volume 

■ 50 per year 
Frequency 

- Weekly 

3. F4anage Inventor)’ Control Mechanisms 

Define procedures for the Gunnery or Weapons Officer ,to make periodic spot 
checks on the accuracy of conunand, inventory, transaction, and serial.'lot number 
data. An enhancement to the system could involve system checking of data entries 
(i.e., checking to ensure that LTC and Command Name match each other from a 
list of Nav)' commands). 







System enhancement could include storage of KAVSEA Publication 
lO-TWO-AA-010, a large reference describing all the available NIINs in the stock 
system. ARM IRS could then check the existence of information entered on the 
Master Stock Record (e.g., checking validity of a NALC). 

GENERATE REQUISITIONS APPLICATION 
1. Generate Requisitions Update Mechanisms 

a. Add a Requisition 
Input 

■ COMMAND object 

■ Document Number, Document Identifier, Requisition De,'Classification, Ad¬ 
dressees, and Remarks from user 

■ Line item data including NALC, NUN, ESC, Project Code, Media,'Status Code, 
Signal Code, Demand Code, Advice Code, Fund Code, Priority, Urgency of 
Need, Required Delivery Date, Status, and Line Classification from the user and 
reference publications. 

Output 

■ REQUISITION object instance 

■ REQN LINE ITEM object instance(s) 

■ Confirmation message on screen 
Processing Notes 

■ All of the information on the Requisition Form (Figure 15) must be completed 
before a requisition can be generated. 

• An item need not be held in inventory to be requisitioned. 

• Initial (default) value for Requisition Status is [U] indicating unfilled. 

Volume 

■ Eight per year (rare while deployed), usually with the majority of line items on 
two large requisitions 

Frequency 

■ Quarterly 

b. Edit Requisition Data 
Input 

■ Update information on a requisition as provided by message or other official 
communication. Requisition Status is almost always the only requisition value 
to change between the time of transmission and material receipt. 

Output 

■ .Modified REQN LINE ITEM object instance 






• Confirmation message on screen 

• Processing Notes 

• The form shown in Figure 15 is retrieved (by Document Number) in a query- 
by-forms edit mode. The corrections are then entered by the user. 

• Changing the requisition attributes (except for Requisition Status which does 
not appear on the transmitted requisition) does not change the transmitted 
requistion. It is necessar)’ to modify or cancel a transmitted requisition with a 
message. 

• The purpose of this update option is to allow requisition status changes to be 
made as status messages are received. 

• The manual system equivalent to this process is to write in a new "Status" entry 
in the Requisition Log on receipt of a requisition status message. 

• Different line items on the same requisition could each have a different status. 
Status is given for one line item. 

• Volume 

• 15 per year 

• Frequency 

■ Monthly 

2. Generate Requisitions Display Mechanisms 
a. Single Requisition Display 

• Output Description 

■ Form displaying information on a requisition (one Document Number) and all 
of its line items (Figure 15). 

• Source data 

• REQUISITION object 

. REQN LINE ITEM object 

■ Document Number entered by user 

• Processing Notes 

■ .Manual system equivalent is to look up a requisition in the Requisition File. 

• Retrieval by NALC or NUN (non-key attributes here) is also possible but may 
be more time consuming because of multiple instances. 

• Volume 

■ 11 times per year 

• Frequency 

■ .VIonthly 


85 





b. Requisition Generation 
Output Description 

■ Report containing all information required of a requisition and its line items as 
shown in Figure 15. 

■ Format for output determined by user selection of a desired format. 

Source Data 

■ COMMAND object 

- REQUISITION object 

- REQN LINE ITEM instance(s) 

• User selection of format desired (DD Form 1348, DAAS, or Naval Message). 
Processing Notes 

■ User selects a menu option for the desired format. 

■ All information on Figure 15 (except Status, which is for internal use) must be 
completed before a requisition can be generated. 

• Information on the ARM IRS ship and the requisitioned activity (COMMAND 
object) must be updated prior to generation of an accurate requisition. 

Volume 

■ 11 per year 
Frequency 

■ Monthly 

c. Turn-In Document Generation 
Output Description 

■ Output in DD Form 1348 format consisting of NUN, Unit Of Issue, Quantity, 
Document Number, COG, Project Code, Unit Price, Service Code, LTC, Name, 
Hull Number, Extended Price, MCC, DOT and USCG Hazmat Codes, Lot or 
Serial Number (if applicable). Short Title, NAR Serial Number (if applicable) 

Source Data 

. TRANSACtiON object 

• COMMAND object 

. AMMO INVENTORY object 

■ SERIAL and'or LOT CONTROLLED AMMO object (if applicable) 
Processing Notes 

■ Document Number is locally assigned and must be sequentially issued. 


• Future enhancement to the system would print the boxes and columns of the 
DD Form 1348 rather than only providing formatted output that must be 
transferred to a DD Form 1348. 

■ Because this function uses all ARM IRS objects (except for REQN & LINE 
ITEM), all forms (except requisitions) must be updated prior to turn-in docu¬ 
ment generation. 

• Volume 

• Four per year 

• Frequency 

• Semiannually 

3. Generate Requisitions Control Mechanisms 

• The system should not allow assignment of duplicate documents numbers or doc¬ 
ument numbers (for the ARM IRS ship) that are out of sequence. 

• Define procedures to allow the Weapons Officer or Gunnery Officer to spot check 
the accuracy of AR.MIRS requisition data by comparing generated requisitions to 
SPCCINST 8010.12D and other instructions. 

C. GENERATE REPORTS APPLICATION 
1. Generate Reports Update Mechanisms 

None. Except for a one field update to TRANSACTION, this is an output-only 
function. 


2. Generate Reports Display Mechanisms 
a. Requisition Log Report 

• Output Description 

■ Report displaying the requisitions issued by a command with data in columns 
for Document Number, NALC, Short Title, Quantity Requisitioned, Required 
Deliver}’ Date, Requisition Status, and Priority. 

• Source Data 

- REQUISITION object 

. REQN LINE ITEM object 

. AMMO INVENTORY object 

• Processing Notes 

• Rows consist of all Document Numbers where Required Deliver}' Date exists 
(since turn-in documents [issue transactions] also are identified by document 
numbers but never have an RDD). 

■ Rows are sorted by Document Number and then by NUN. 

• Displays summar}’ and status information on all requisitions, regardless of sta¬ 
tus. 


t. 


87 






Volume 

• 18 times per year 
Frequency 

• Monthly 

b. Maintenance Due Summary Report 
Output Description 

• Report summarizing maintenance due information on serially controlled items 
and containing columns for NALC, Short Title, Serial Number, Maintenance 
Due Date, and Maintenance Type. 

Source Data 

- SERIAL CONTROLLED AMMO object, or 

- SERIAL & LOT CONTROLLED AMMO object 

- AMMO INVENTORY object 
Processing Notes 

■ All ammunition items with serial numbers are displayed on this report. 

■ The rows on the report are sorted by NALC and then by Serial Number. 

• Maintenance Due Type may be blank for some rows. Only torpedoes and air- 
launched missiles have a value assigned. 

Volume 

■ Four per year 
Frequency 

• Quarterly 

c. Ship Ammunition Listing 
Output Description 

■ A report of ammunition held (without quantities) containing columns for COG, 
NALC, and Short Title. 

Source Data 

• AMMO INVENTORY object 
Processing Notes 

• This report is a list of ammunition types held onboard. It does not include the 
quantities found on inventory reports (See TRANSACTION object). 

■ Equivalent report from the manual system is processed by sorting through the 
.Master Stock Record Cards (in NALC groups) and copying the COG, NALC, 
and Short Title from the card header information. 


88 


• Report rows are sorted by COG and then by NALC. 

Volume 

• 16 per year 
Frequency 

■ Monthly 

d. Allowance List Report 
Output Description 

■ Columns for COG, NALC, Short Title, Shipfill Allowance, and Training Al¬ 
lowance (NCEA). 

Source Data 

- AMMO INVENTORY object 
Processing Notes 

■ This report summarizes the NAVSEA (shipfill) and NCEA (training) allowances 
held by the ship. 

■ Some NALC NTIN items held onboard do not have shipfill or training allow¬ 
ances. As a result, some rows will have a zero under the Shipfill Allowance 
and or Training Allowance columns. 

• The manual equivalent to this report would be to create a list of NIINs and then 
use the two allowance lists to add allowance data for each NUN. 

• Rows sorted by COG, NALC, and then NUN. 

Volume 

• Four per year 
Frequency 

■ Quarterly 

e. NAR Management Report 
Output Description 

• Report containing columns for NAR Serial Number, NALC, Short Title, Lot 
Number (if applicable), and Condition Code. 

Source Data 

» AMMO INVENTORY object 

- TIL^NSACTION object 

- LOT and/or SERIAL CONTROLLED AMMO objects (if applicable) 
Processing Notes 






■ This report is used by the Gunnery Officer to cross reference Notices of Am¬ 
munition Reclassification with the onboard ammunition inventory. It is also 
used to prevent missing NARs. 

■ The only NIINs of interest here are the ones corresponding to NARS. This re¬ 
port selects all NUNS where a NAR Serial Number exists. 

• The instances on this report are sorted by NAR Serial Number, and are there¬ 
fore in chronological order. 

• Equivalent in the manual system to going through the NAR File and checking 
against the .Master Stock Record Cards to extract "active" NARs refering to 
ammunition held by the command. 

• Volume 

■ 16 times per year 

• Frequency 

■ Monthly 

/. Allowance Tracking Report 

• Output Description 

■ Report containing columns for NALC, Short Title, Quantity, Shipfill Allow¬ 
ance, NCEA Balance (quantity unexpended for the current fiscal year's 
traininng allowance), and Percent of Shipfill Allowance onboard. 

• Source Data 

• A.M.MO INVENTORY object 

- TRANSACTION object 

• Processing Notes 

• NCEA Balance is calculated by adding all balance changes for the fiscal year 
where there is a Quantity Expended reported. This total is then subtracted from 
the Training Allowance for that ammunition type. 

■ On 01 October of each year, the NCEA Balance is set equal to the ship's 
Training Allowance. 

• Percentage of Shipfill Allowance is a calculated value not stored in the database. 
It is used on summar>' reports only. 

• Equivalent processing in the manual system would require checking the trans¬ 
actions (since 01 October of the current fiscal year for NCEA) on the stock 
cards and comparing these sums against the NAVSEA Ship Allowance and the 
NCEA Training Allowance for each applicable NALC. 

• Unlike the Allowance List Report which only includes the allowances and not 
the inventory quantities, this report assists the Gunnery Officer in planning the 
requisitioning and expenditure of ammunition to remain close to 100 percent 
of Shipfill Allowance while ensuring that ammunition expenditures do not ex¬ 
ceed the fiscal year training allowance. 
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Volume 

■ 15 per year 
Frequency 

■ Monthly 

g. Ammunition Transaction Report (ATR) 

Output Description 

■ A formatted message containing all of the properties shown on the "Stock His- 
toiy’" and "Transaction Reporting" sections of Figure 13 (except for Price which 
is only used for turn-in documents). 

Source Data 

■ COMMAND object (LTC, Name, Service Code) 

■ AMMO INVENTORY object (NALC, FSC, NTIN, COG, MCC, ACC, and 
Sonobuoy Channel [if applicable]) 

■ TRANSACTION object (except for Price) 

• SERIAL and/or LOT CONTROLLED AMMO objects (if applicable) 

• ATR Addressees and ATR Classification from the expert database module (if 
used) or from user input. 

Processing Notes 

■ The generated ATR should be ready to transmit through Naval telecommuni¬ 
cations channels. 

■ The ATR may vary in length from one transaction (about 3 or 4 lines on the 
finished report) to up to six pages of transactions. 

Volume 

■ 60 per year, within 48 hours of every transaction 
Frequency 

■ Weekly, highly variable 

h. A TR Log Report 
Output Description 

■ Report showing the ATRs sent by the ship and containing columns for ATR 
Serial Number, ATR Line Number, Short Title, Quantity Expended / Issued / 
Received, Condition Code, and Quantity. 

Source Data 

■ TRANSACTION object (all instances) 

Processing Notes 





• Each line on this report represents an instance of the TRANSACTION object 
(since each transaction must have an ATR serial and line number). 

• Sorting of data rows is by ATR Serial Number and then by ATR Line Number. 

• ATR Serial Numbers must be sequentially assigned with no gaps in the se¬ 
quence. 

■ In the manual system, the ATR Log performs the function of this report, al¬ 
lowing a quick reference to key information on transaction reports and serving 
as the source of ATR Serial Numbers. 

• Volume 

• 30 times per year 

• Frequency 

■ Biweekly 

/. SOR TS Message Input Report 

• Output Description! 8 

■ Report sent as a memo from the Weapons Officer to the Operations Officer ■ 
providing input for a message on combat readiness impact of ammunition stock 
levels (among other readiness factors). 

■ Columns for Mission Area (i.e., ASW, AAW, etc.), NALC, Short Title, Quan¬ 
tity, Shipfill Allowance, and Percent of Allowance Onboard. 

• Source Data 

- AMMO INVENTORY object (Mission, NALC, Short Title, Shipfill 
Allowance,Quantity) 

• Processing Notes 

■ Percentage of Allowance Onboard is not a database property but is a calculated 
value used for reports. 

• Data rows are sorted first by Mission Area and then by NALC. 

■ Only NALCs with Mission Areas assigned are shown on this report. (For ex¬ 
ample, small arms ammunition and pyrotechnics do not have assigned combat 
mission areas and would not appear.) 

■ Some of the rows on this report could be duplicated, since it is recognized that 
one NALC may have more than one mission area (e.g., a 5-inch gun projectile 
used for both ASUW and AMW). 

• Volume 

• 50 per year 

• Frequency 


18 LT Thomas P. Fortin, USN* provided valuable input on the readiness reporting require¬ 
ments of ammunition inventoiy information. 
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- Weekly 


j. Ship Ammunition Inventory Report (Summary) 

Output Description 

■ Inventor}' report including columns for GOG, NALC, NUN, Short Title, and 
Quantity. 

Source Data 

• AMMO INVENTORY object 

■ TR.ANSACTION object 
Processing Notes 

■ This report presents summary inventory information and does not subivide 
NALC and NIIN into lots or serially numbered rounds. 

■ The quantities of all NIINs onboard are represented on this report. 

■ Rows are sorted by COG, by NALC, and then by NIIN. 

Volume 

■ 50 per year 
Frequency 

■ Weekly 

k. Turn-In Log Report 
Output Description 

■ Report containing columns for Document Number, Date, Consignee, Short Ti¬ 
tle, and Quantity Issued. 

Source Data 

. TIUNSACTION object 
. AMMO INVENTORY object 
Processing Notes 

■ This report summarizes the command's history of turn-in (ammunition offload) 
documents. 

■ Each Document Number where an Issue Code exists is represented by a row 
on this report. 

■ Data rows are sorted by Date and then by Document Number. 

Volume 

■ Four times per year 
Frequency 

• Quarterly 





/. Ship Ammunition Inventory Report (Detailed) 

• Output Description 

• Inventor}' report featuring columns for NALC, NUN, Short Title, Lot Number, 
Serial Number, and Quantity. 

• Source Data 

• SERIAL and/or LOT CONTROLLED AMMO object(s) 

- AMMO INVENTORY object 

• Processing Notes 

■ This reports subdivides NTINs by serial and lot number. It is more detailed than 
the "Ship Ammunition Inventory Report (Summary)" and is required less fre¬ 
quently. 

■ Data for the Lot Number and Serial Number columns will be absent for 
non-SLIT items. 

• The rows will be sorted by NALC and then by NUN. 

• Volume 

■ 12 per year 

• Frequency 

• Monthly 

m. Outstanding Requisition Summary Report 

• Output Description 

■ Report on unfilled requisitions consisting of columns for Document Number, 
NUN, NALC, Short Title, RDD, Priority, and Quantity Requisitioned. 

• Source Data 

. REQUISITION object 

• REQN LINE ITEM object 

• Processing Notes 

■ All Document Numbers where Requisition Status is (UJnfilled are sorted first 
by Document Number and then by NT IN. 

• Equivalent action in the manual system is to page through the Requisition Log 
and find all entries where the Requisition Status shows that the requisition is 
outstanding. 

• Volume 

■ 12 per year 

• Frequency 

• M onthly 

L 
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3. Generate Reports Control Mechanisms 

• Send output to screen or printer at user option. 

• Provide setup routines where a printer can be designated. 
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APPENDIX F. RELATIONAL SCHEMA 
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Figure 16. ARM IRS Relation Diagram (__= key, * = foreign key) 
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Continued Continued Continued Command 

Information 
Form 
(Fig. 12) 


Figure J7, Hierarchy for Main and Secondarj’ Menus 
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Inventory Information 
Form 

(Figure 13) 


Serlal/Lot 
Record Form 
(Figure M) 


Inventory 
Information 
Form (Figure 
13) 


Figure 18. Hierarchy for Menu 1 (Inventor)') 
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Figure 20. Hierarchy for Menu 3 (Generate Reports) 
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APPENDIX H. LOGIC SPECIFICATIONS 


A. MENU 0 (MAIN MENU) 

Until ESC entered: 

• Display ARMIRS Main Menu (Figure 17) 

1. Inventory Management 

2. Requisition,'Tum-In 

3. Reports 

4. Ship Information 

5. Exit to Operating System 

• Get menu choice from user 

• Confirm menu choice 

• Case menu choice 

1. Go to Menu 1 (Inventoiy Management, Figure 18) 

2. Go to Menu 2 (Requisition,'Turn-In, Figure 19) 

3. Go to Menu 3 (Report Generation, Figure 20) 

4. Go to Menu 4 (Ship Information, Figure 17) 

5. Exit to operating system prompt 

• Else ESC 

B. MENU 1 (INVENTORY MENU) 

Until ESC entered: 

• Display Menu 1 

• Get menu choke from user [1,2,3] 

• Confirm menu choice 

• Go to selected menu choice 

1. Menu I-l (Master Stock Records) 

Until ESC entered: 

• Display Menu 1-1 

• Get menu choice from user [1,2,3] 

• Confirm menu choice 

• Go to selected menu choice 
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a. Append Master Stock Records 

• Display Inventory Information Form (Figure 13) 

• Get XALC from user 

• Get FSC from user 

• Get XIIN from user 

• Get Short Title from user 

• Get COG from user 

• Get MCC from user 

• Get Unit of Issue from user 

• Get Sonobouy Channel (optional) from user 

• Get Shipfill Allowance from user 

• Get Mission Allowance from user 

• Get XCEA from user 

• Get Location(s) (optional) from user 

• Get USCG Hazmat Code from user 

• Get DOT Hazmat Code from user 

• Get XHEEW from user 

• Get Unit Price from user 

• Get Missions Area(s) (optional) from user 

• Get Uow Stock Uevel (default = 50%) from user 

• Display confirmation message 

• Store inventor)’ data 

b. Edit Master Stock Records 
Until ESC entered: 

• Get XT IN (or other inventor}' property) from user 

• Display top part of Inventory Information 1 orm (Figure 13) for desired stock re¬ 
cord 

• Get any (optional) revisions from user 

• Display confirmation message 

• Store revised inventor)’ data 
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c. Query or Display Master Stock Records 
Repeat until ESC entered: 

• Get NUN (or other inventory property) from user 

• Display top part of Inventor}' Information Form (Figure 13) for desired stock re¬ 
cord 

2. Menu 1-2 (Serial-Lot Records) 

Until ESC entered: 

• Display Menu 1-2 

• Get menu choice from user [1,2,3] 

• Confirm menu choice 

• Go to selected menu choice 

a. Append Serial and Lot Stock Records 

• Display Serial, Lot Record Form (Figure 14) 

• Get NIIX from user 

• If XIIN does not exist then: 

- Displav:"YOU MUST FIRST CREATE A MASTER STOCK RECORD FOR 
THIS ITEM BEFORE CREATING SERIAL OR LOT RECORDS" 

• Display Short Title from database 

• Display NALC from database 

• Display COG from database 

• Display Remarks from database 

• Get Serial Number (optional) from user 

• Get Lot Number (optional) from user 

• If Serial Number exists then: 

• Get Maintenance Due Date from user 
■ Get Maintenance Due Type from user 

• Get Location from user 

• Display confirmation message 

• Store serial and lot data 

b. Edit Serial and Lot Stock Records 
Repeat until ESC entered: 

• Get Serial Number or Lot Number (or other property) from user 
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• Display Serial,'Lot R.ecord Form (Figure 14) for desired record 

• Get any (optional) revisions from user 

• Store revised serial and lot data 

c. Query or Display Serial and Lot Stock Records 
Until ESC entered: 

• Get Serial Number or Lot Number (or other property) from user 

• Display Serial’Lot Record Form (Figure 14) for desired record 

3. Menu 1-3 (Process Transactions) 

Unil ESC entered: 

• Display Menu 1-3 

• Get menu choice from user [1,2,3] 

• Confirm menu choice 

• Go to selected menu choice 

a. Add Transaction 
Until ESC entered: 

• Get NUN (or other inventory property) from user 

• If NUN does not exist then: 

. Display: "YOU MUST FIRST CREATE A MASTER STOCK RECORD BE¬ 
FORE PROCESSING TRANSACTIONS ON THIS NUN." 

• Display selected Inventory Information Form (Figure 13) 

• Get new transaction data from user 

• If transactions changes quantity on hand then: 

■ Update AMMO INVENTORY.Quantity on Hand (post transaction to Master 
Stock Record) 

■ If Serial Number or Lot Number exists then: 

A Update quantity in SERIAL and'or LOT CONTROLLED AM.MO 

• If Serial Number or Lot Number exists then: 

■ Update all (user-entered) values to SERIAL and/or LOT CONTROLLED 
AM.MO 

b. Delete Transaction 
Until ESC entered: 

• Get NUN (or other inventory property) from user 
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• If XI IN does not exist then; 

. Displav: "NUN REQUESTED FOR TRANSACTION DELETION DOES 
NOT EXIST IN INVENTORY. PLEASE TRY AGAIN." 

• Display selected Inventory Information Form (Figure 13) 

• Get transaction line to delete from user 

• Update AMMO INVENTORY.Quantity on Hand 

• Delete (user-selected) line for ATR Serial Number and ATR Line Number. 

• If Serial Number or Lot Number exists then: 

• Delete selected transaction from SERIAL and/or LOT CONTROLLED 
AMMO 

• Display deletion confirmation message 

c. Edit Transaction 
Until ESC entered: 

• Get NUN (or other inventoiy property) from user 

• Display selected Inventory Information Form (Figure 13) 

• Get any (optional) revisions to TRANSACTION from userl9 

• Display confirmation message 

• Store revised transaction data 

C. MENU 2 (REQUISIT )N/TURN-IN MENU) 

Until ESC entered: 

• Display Menu 2 

• Get menu choice from user {1,2,3,4] 

• Confirm menu choice 

• Go to selected menu choice 

1. Append Requisitions 

• Display Requisition Information Form (Figure 15) 

• Get Document Number from user 

• If Document Number exists then: 

. Displav; "THIS DOCUMENT NU.MBER HAS ALREADY BEEN AS¬ 
SIGNED, SEE THE REQISITION OR TURN IN-LOG FOR .MORE IN¬ 
FORMATION," 

19 Used to modify an unposted transaction only. 
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• Get Document ID from user 

• Get Classification from 

• If Classification = [C] then: 

■ Get Declass Date from user 

• Get Remarks from user 

• Get Addressees from user 

• For each requisitioned item: 

■ Get XALC from user 

• Get NUN from user 

• l;.:>piay FSC from database 

• Get Quantity from user 

• Get Project Code from user 

• Get Media and Status Code from user 

• Get Signal Code from user 

■ Get Demand code from user 

• Get Advise Code from user 

■ Get Fund Code from user 

■ Get Priority from user 

■ Get Urgency of N - ed from user 

■ Get Required Deliver}’ Date from user 

■ Get Status (optional, default = [U]nfilled) from user 

■ Get Line Classification (default = (Ujnclassified) from user 

• Display confirmation message 

• Store requisition data 

2. Edit Requisitions 
Until ESC entered: 

• Get Document Number (or other requisition property) from user 

• Display Requisition Information Form (Figure 15) 

• Get any (optional) revisions from user 

• Display confirmation message' 

• Store revised requisition data 

I. 
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3. Quer}’ or Display Requisitions 
Repeat until ESC entered: 

• Get Document Number (or other requisition property) from user 

• Display Requisition Information Form (Figure 15) for desired requisition record 

4. Menu 2-4 (Generate Requisitions or Turn-Ins) 

Until ESC entered: 

• Display Menu 2-4 

• Get menu choice from user [1,2,3,4] 

• Confirm menu choice 

• Go to selected menu choice 

a. Generate DD Form 1348 Requisition 
Until ESC entered: 

• For selected Document Number 

. Display "DD FORM 1348 REQISITION INPUT" 

■ Generate Pleader Line: 

A Display Document Identifier 
A Display Media and Status Code 
A Display FSC 
A Display NUN 
A Display Unit Of Issue 
A Display Requisition Quantity 
A Display Service Code 
A Display Document Number 
A Display Fund Code 
A Display COG 
A Display Project Code 
A Display Priority 
A Display Required Deliver}’ Date 
A Display Advice Code 

■ Display "A." (UTC, Name, Hull Number, Location for own ship] 

■ Display "B." [UTC, Name, Hulf Number, Location for other command] 
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■ Display "T. DOT CLASS" [DOT Hazmat Code] "CG CLASS" [USCG Hazmat 
Code] 

- Display "W." [NALC] 

- Display "X." [Short Title] 

- Display "BB. LIVE AMMO" 

b. Generate DD Form 1348 Turn-In 
Until ESC entered: 

• For selected Document Number where Issue Code exists: 

- Display "DD FORM 1348 TURN-IN INPUT" 

- Display "HEADER LINE:" 

A Display FSC 

A Display NUN 
A Display Unit of Issue 
A Display Service Code 
A Display Document Number 
A Display COG 
A Display Project Code 
A Display Unit Price 

• Display "A." [UTC, Name, Hull Number, Location for own ship] 

• Display "B." [UTC, Name, Hull Number, Location for other command] 

■ Display "E." [Extended Price] 

■ Display "P." [Material Condition Code] 

■ Display "T. DOT CLASS" [DOT Hazmat Code] "CG CLASS" [USCH Hazmat 
Code] 

• Display "V." [Lot Number] 

■ Display "V." [Serial Number] 

- Display "W." [NALC] 

■ Display "AA." [NAR Serial Number] 

- Display "BB. LIVE AMMO" 

c. Generate DA AS Requisition 
Until ESC entered: 

• For selected Document Number 

■ Display "UNCLASSIFIED" 
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- Display "LMF = TT CIC=ZYUW'' 

■ Display "FROM:” (Command Name] 

- Display "TO: DAAS DAYTON OH" 

- Display "INFO:" [Addressees] 

- Display "SUBJ: AMMO MILSTRIP REQN" 

■ For each NUN (requisition line]: 

A Display Document Identifier 

▲ Display Media and Status Code 
A Display NIIN 

▲ Display Quantity 

A Display Document Number 
A Display Demand Code 
A Display Signal Code 
A Display Project Code 
A Display Priority 
A Display Required Deliver}' Date 
A Display Advice Code 

</. Generate Naval Message Requisition 
Until ESC is entered: 

• For a selected Document Number: 

• Display "CLASSIFICATION:" (Classification] 

■ If Classification = C then: 

A Display "DECLAS:" (Declas Date] 

• Display "FROM: "(Conmiand Name] 

- Display "TO: SPCC MECHANTCSBURG PA" 

• Display "INFO:" (Addressees] 

■ Display (Classification]'7/NO80I0//" 

- Display "AMMO MILSTRIP REQUISITION" 

■ Display "1. ("(Classification]")" 

■ For each NUN (requisition line): 

A Display (Document Identifier]"/" 

A Display "NCB/" 
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A Display (Media and Status Code]”/" 

A Display (FSC]{NI1N]"/" 

A Display (Quantity of Issue]"/" 

A Display (Quantity]"/" 

A Display (Document Number]"/" 

A Display (UIC]"/" 

A Display (Signal Code]"/" 

A Display (Fund Code]"/" 

A Display (Project Code]"/" 

A Display (Priority]"/" 

A Display (Required Deliver}' Date]"/" 

A Display Advice Code 

■ Display "2. ((Line Classification]")" (Remarks] 

■ Display "DECLAS:"(Declas Date] 

D. MENU 3 (GENERATE REPORTS MENU) 

L'nil ESC entered: 

• Display Menu 3 

• Get menu choice from user (1,2,3] 

• Confirm menu choice 

• Go to selected menu choice 

1. Menu 3-1 (Inventory Reports) 

Until ESC entered: 

• Display Menu 3-1 

• Get menu choice from user (1,2,3,4,5,6,7,8] 

• Confirm menu choice 

• Go to selected menu choice. 

a. Inventory Summary Report 
Until ESC entered: 

• Display "AMMUNITION LISTING" 

• Display (today's date] 

• Display "COG.,.NALC...NA.ME" 

• For all NUN in database sort by COG then NUN: 
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■ Display COG 

■ Display NALC 

■ Display Short Title 

b. Allowance List Report 
Until ESC entered: 

• Display "ALLOWANCE LIST REPORT" 

• Display [today's date) 

• Display "KALC..NI1N...NAME...SHIPFILL ALLOW...TRAINING ALLOW." 

• For all NUN in database where Shipfill Allowance exists OR where Training Al¬ 
lowance exists, sort by COG then NALC then NIIN: 

■ Display NALC 

• Display NUN 

• Display Short Title 

• Display Shipfill Allowance 

• Display Training Allowance 

c. NAR Management Report 
Until ESC entered: 

• Display "NAR MANAGEMENT REPORT" 

• Display [today's date) 

• Display "NAR #...NALC...NAME...LOT CON'D. CODE" 

• Select all from database where NAR Serial Number exists, sort by NAR Serial 
Number: 

• Display NAR Serial 

• Display NALC 

• Display Short Title 

• Display Lot Number 

• Display Condition Code 

d. Allowance Tracking Report 
Until ESC entered: 

• Display "ALLOWANCE TPjVCKING REPORT" 

• Display [today's date) 

• Display "NALC...NAME...QTY...ALLOW...NCEA..NCEA BAL..PCT ALLOW" 
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Select all from database where Training Allowance exists OR Shipfill Allowance 
exists, sort by NALC then by Short Title: 

■ Display NALC 

■ Display Short Title 

■ Display Quantity 

■ Display Shipfill Allowance 

• Display NCEA Balance 

■ Display (Quantity,'Shipfill Allowance)* 100 

e. SOR TS Message Input Report 
Until ESC entered: 

Display (today's date] 

Display "FROM: WEAPONS OFFICER" 

Display "TO: OPERATIONS OFFICER" 

Display "SUBJ: INPUT FOR SORTS MESSAGE" 

Display "MISSION...NAUC...ITEM...QTY...AUUOW...PCT OF AUUOW" 

Select all where Mission Area exists, sort by Mission Area then by NALC: 

• Display Mission Area 

■ Display NALC 

■ Display Short Title 

■ Display Quantity 

■ Display Shipfill Allowance 

■ Display (Quantity/Shipfill Allowance)* 100 

/. Ship Ammunition Inventory Report (Summary) 

Until ESC entered: 

Display "SHIP AMMUNITION INVENTORY REPORT (SUMMARY)" 
Display "(MASTER STOCK RECORDS ONLY)" 

Display [today's date] 

Display "COG...NALC..NTIN...ITEM...QTY" 

Select all, sort by COG then NALC then NUN: 

■ Display COG 

• Display NALC 

■ Display NUN 



■ Display Short Title 

■ Display Quantity 

g. Ship Ammunition Inventory Report (Detailed) 

Until ESC entered: 

• Display "SHIP AMMUNITION INVENTORY REPORT (DETAILED)" 

• Display "(INCLUDING LOT AND SERIAL ITEMS)" 

• Display [today's date] 

• Display "NALC..NHN...ITEM...LOT NR...SERIAL NR...QTY" 

• Select all, sort by NALC then by NUN: 

■ Display NALC 
^ Display NUN 

■ Display Short Title 

■ Display Lot Number 

• Display Serial Number 

■ Display Quantity 

h. Maintenance Due Summary Report 
Until ESC entered: 

• Display "MAINTENANCE DUE SUMMARY REPORT" 

• Display [today’s date] 

• Display "NALC..ITEM...SERIAL NR...MAINT DUE...MAINT TYPE" 

• Select all where Serial Number exists, sort by NALC then by Serial Number: 

■ Display NALC 

• Display Short Title 

• Display Serial Number 

■ Display Maint Due Date 

■ Display Maint Due Type 

2. Menu 3-2 (Generate Transaction Reports) 

Until ESC entered: 

• Display Menu 3-2 

• Get menu choice from user [1,2] 

• Confirm menu choice 

• Go to selected menu choice • 
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a. Generate A TR 


Until ESC entered: 

• Display: "CLASSIFICATION:" [ATR Class] 

• If ATR Class = C then: 

• Display "DECLAS:"(ATR Declas Date] 

• Display "FM:"(Coniniand Name] 

• Display "TO: SPCC MECHANTCSBURG PA" 

• Display 'TNFO:"[ATR Adressees] 

• If ATR Class = C then: 

. Display "C O N F I D E N T I A L//NO8015//" 

• Else 

• Display "UNCLAS//NO8015//" 

• Display "SUBJ: AMMO TRANS RPT RCS SPCC 8010-12" 

• Display Header Line: 

. Display "'///[UIC],'[ATR Serial]j[ACC]/[Julian Date]///" 

• For each transaction: 

- If Non-SLIT (MCC <> C) item: 

▲ Display "//;[NALC](NT IN]/(Condition Code]//B[01d Balance]//[Transaction 
Code][Quantity]/[Consignee)/(Document Number],'/[New Balance],'//" 

- Else (MCC = C): 

A Display"///[NALC][NnN].’[Condition Code]/,'B[01d Balance].'/[Transaction 
Code]; [Serial Number] ([Maint Due Date] [Maim Due Type])/ [Consignee] 
/[Document Number]/ [New Balance]///" 

• Display"////" 

b. A TR Log Report 
Until ESC entered: 

« Display "AMMUNITION TRANSACTION LOG" 

• Display [today's date] 

• Display "ATR # ... ATR LINE ... ITEM ... QTY EXPEND ... QTY ISS ... QTY 
RCVD ... COND CODE ... BALANCE" 

• Select all where ATR Serial Number exists, sort by ATR Serial Number and then 
by ATR Line Number: 

■ Display ATR Serial Number 

• Display A fR Line Number 
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• Display Short Title 

■ Display Quantity Expended (if any) 

■ Display Quantity Issued (if any) 

■ Display Quantity Received (if any) 

■ Display Condition Code 

• Display Balance 

3. Menu 3-3 (Requisition & Tum-In Reports) 

Until ESC entered: 

• Display Menu 3-3 

• Get menu choice from user [1,2,3] 

• Confirm menu choice 

• Go to selected menu choice 

a. Requisition Log Report 
Until ESC entered: 

• Display "REQUISITION UOG REPORT" 

• Display [today's date] 

• Display "DOCUMENT #...NALC...ITEM...QTY...RDD...STATUS...PRr' 

• Select all Document Numbers where Required Delivery Date exists, sort by Docu¬ 
ment Number and tlien oy NT IN: 

■ Display Document Number 

■ Display NALC 

■ Display Short Title 

■ Display Quantity 

■ Display Required Deliverv’ Date 

■ Display Status 

■ Display Priority 

b. Turn-In Log Report 
Until ESC entered: 

• Display "TURN-IN LOG REPOP-T" 

• Display [today's date] 

• Display "DOCUMENT NR..DATE..,TO...ITEM-QTY" 
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• Select all Document Numbers where Issue Code exists, sort by Date and then 
Document Number: 

• Display Document Number 

• Display Date 

■ Display Consignee 

• Display Short Title 

■ Display Quantity 

c. Outstanding Requisition Report 
Until ESC entered: 

• Display “OUTSTANDING REQUISITION SUMMARY REPORT" 

• Display (today's date) 

• Display "DOCUMENT NR ... NAUC ... NUN ... ITEM ... REQD DEU DATE ... 
PRI ... QTY" 

• Select all Document Numbers where Requisition Status = U, sort by Document 
Number then NUN: 

• Display Document Number 

■ Display NALC 

■ Display NUN 

■ Display Short Title 
- Display RDD 

• Display Priority 

• Display Requisition Quantity 

E. MENU 4 (COMMAND INFORMATION MENU) 

Until ESC entered: 

• Display Menu 4 

• Get menu choice from user [1,2] 

• Confirm menu choice 

• Go to selected menu choice 

1. Edit Command Information 
Until ESC entered: 

• Display Command Information Form (Figure 12) 

• GetUTC 

• Get Command Name 
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Get Hull Number 
Get Fleet 
Get Service Code 
Get Location 

Get Activity Classification Code 
Get any (optional) revisions from user 
Display confirmation message 
Store revised command data 

2. Display Command Information 
Until ESC entered: 

Display the Command Information Form (Figure 12) 


APPENDIX I. PARADOX TABLES 
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Restructuring M_inv table 


STRUCT=n 

.n-ni-Field Name ' ■ 

rFielc Type^ 

1 

NUN 

A9* 

2 

NALC 

A4 

3 

FSC 

A4 

4 

Short Title 

A20 

5 

COG Symbol 

A2 

6 

Unit Price 

$ 

7 

Sonobouy Channel 

N 

8 

Shipfill Allowance 

N 

9 

Warning Level 

N 

10 

Mission Allowance 

N 

11 

Annual Training Allowance 

N 

12 

Unit of Issue 

A2 

13 

CG Hazmat Class 

A4 

14 

MCC 

A1 

15 

Inv-Remarks 

A30 

16 

DOT Hazmat Code 

A2 

17 

NHEEW 

AlO 

18 

Quantity on Hand | 

N 


- FIELD TYPES - 

A_: Alphanumeric (ex; A25) 
Any combination of 
characters and spaces 
up to specified width. 
Maximum width is 255 

N: Numbers with or without 
decimal digits. 

$: Currency amounts. 

D: Dates in the form 
mm/dd/yy, dd-mon-yy, 
or dd.mm.yy 


Use after field type to 
show a key field (ex: A4*). 


Figure 21. AMMO INVENTORY Object Materialization 
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I - 

Figure 22. 



Detail Tables for INVENTORY Master Table 
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Restructuring Ain_iniss table 


STRUCT=jf 

■■ ■ -ii ■n—Field Ndin6®®= 

“jfField Type 

1 

NUN 

A9 

2 

Mission Area 

A4 


Figure 23. Mission Area DetailTable for INVENTORY 
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Restructuring Ain_bal table 


STRUCT-s 

Name"""**'"'"™ 

‘Field Typei 

1 

NUN 

A9 

2 

ATR Serial Number 

A3 

3 

ATR Line Number 

N 

4 

Document Number 

A14 

5 

Julian Date 

A4 

6 

Old Balance 

N 

7 

Quantity Issued 

N 

8 

Quantity Received 

N 

9 

Receipt Code 

A6 

10 

Issue Code 

A6 

11 

Loss Code 

A5 

12 

Extended Price 

$ 

13 

Trng Allow, to Charge 

A5 

14 

Quantity Expended 

N 

15 

Transaction Type 

A2 

16 

Consignee/Consignor 

A5 

17 

Balance Serviceable 

N 

18 

Balance Unserviceable 

N 

19 

Training Allowance Unexp. 

N 

20 

Quantity Due In 

N 

21 

Condition Code 

A1 

22 

Revised Condition Code 

A1 


Restructuring Ain_bal table 


STRUCT=i 

. - Field Name — 

fField Type^ 

23 

Remarks-Balchg 

A30 

24 

Referenced ATR 

A3 

25 

NAR Serial 

N 

26 

ATR Class 

A1 

27 

ATR Declas 

D 

28 

Lot Number 

A16 

29 

Serial Number 

A16 


Figure 24 . TRANSACTION Detail Table for INVENTORY 
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Restructuring Ain_loc table 



Field Naroe= 

NUN 

Stowage Location 


fField Type^ 
A9 
A12 


Figure 25. Stowage Locations Detail Table for INVENTORY 
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Restructuring Ain_rln table 

Field Type 
A9 
N 
A3 
A1 
A1 
A1 
A2 
A2 
A1 
A3 
A1 
A1 
A2 
A14 


Figure 26. REQN LINE Detail Table for INVENTORY 


STRUCT-if===—=«Field Name 

1 NUN 

2 Reqn Quantity 

3 Project Code 

4 Media Status Code 

5 Signal Code 

6 Demand Code 

7 Advice Code 

8 Fund Code 

9 Urgency of Need 

10 Required Delivery Date 

11 Status 

12 Line Class 

13 Priority 

14 Document Number 
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Restructuring Am^lot table 

STRUC T ii Field Name - Field Type 

1 NUN A9 

2 Lot Number A16 


Figure 27. LOT AMMO Detail Table for INVENTORY 
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Restructuring Ain_ser table 


STRUCT* 

1 

j~ Field Hame- ■ 

NUN 

fField Type^ 
A9 

2 

Serial Number 

A16 

3 

Maint. Due Date 

A3 

4 

Type of Maint. Due Code 

A1 

5 

Condition 

A1 

6 

1 Stowage Location 

A12 


Figure 28. SERIAL AMMO Detail TabJe for INVENTORY 
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Restructuring Ain_s&l table 


STRUCT*! 

-Field Naine==— 

fField Type^ 

1 

NUN 

A9 

2 

Serial Number 

A16 

3 

Lot Number 

AT6 

4 

Maint. Due Date 

A3 

5 

Type of Maint. Due Code 

A1 

6 

Condition 

Al 

7 

Stowage Location 

A12 


Figure 29. SERIAL & LOT AMMO Detail Table for INVENTORY 
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Restructuring M_balchn table 


STRUCT=n 

-Field Name- 

fField Type^ 

1 

ATR Serial Number 

A3* 

2 

ATR Line Number 

N* 

3 

Document Number 

A14 

4 

Julian Date 

A4 

5 

Old Balance 

N 

6 

Quantity Issued 

N 

7 

Quantity Received 

N 

8 

Receipt Code 

A6 

9 

Issue Code 

A6 

10 

Loss Code 

A5 

11 

Extended Price 

$ 

12 

Trng Allow, to Charge 

A5 

13 

Quantity Expended 

N 

14 

Transaction Type 

A2 

15 

Consignee/Consignor 

A5 

16 

Balance Serviceable 

N 

17 

Dalance Unserviceable 

N 

18 

Training Allowance Unexp. 

N 

19 

Quantity Due In 

N 

20 

Condition Code 

A1 

21 

Revised Condition Code 

A1 

22 

Remarks-Balchg 

A30 


Restructuring M_balchn table 


STRUCT=^ 

---Field Name-• 

fField Type^ 

23 

Referenced ATR 

A3 

24 

NAR Serial 

N 

25 

ATR Class 

A1 

26 

ATR Declas 

D 


30. TRANSACTION Object Materialization 










Restructuring B_aaddr table 

STRUC T j| ■■ -- - F ield Name ■ .. Field Type 

1 ATR Serial Number A3 

2 ATR Addressees A30 


Figure 31. ATR Addressees Detail Table for TRANSACTION 
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Restructuring Lot_loc table 

STRUCT [■ " Field Name -j| Field Type 

1 Lot Number A16 

2 Stowage Location A12 


Figure 32. Storage Locations Table 




Restructuring M_us table 


STRUCT*! 

-Field Name- 1 

fField Type=j] 

1 

S-UIC 

A5* 

2 

S-Naroe 

A30 

3 

S-Hull Number 

A8 

4 

S-Service Code 

A1 

5 

S-Location 

A30 

6 

S-Fleet 

A4 

7 

S-FAD 

N 

8 

S-Activity Code 

A1 


Restructuring M_other table 


STRUCT^ 

-Field Name .- ■ 

fField Type=j| 

1 

0-UIC 

A5* 

2 

0-Name 

A30 

3 

0-Hull Number 

A8 

4 

0-Service Code 

A1 

5 

0-Location 

A30 

6 

0-Fleet 

A4 

7 

0-FAD 

N 

8 

0-Activity Class Code 

A1 


Figure 33. COMMAND Object Materialization 
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Figure 34. Detail Tables for COMMAND master Table 
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Restructuring Us_inv table 


STRUCT=j 

Field Name ■ " ■ 

pField Type^ 

1 

S-UIC 

A5 

2 

NUN 

A9 

3 

NALC 

A4 

4 

FSC 

A4 

5 

Short Title 

A20 

6 

COG Symbol 

A2 

7 

Unit Price 

$ 

8 

Sonobouy Channel 

N 

9 

Shipfill Allowance 

N 

10 

Warning Level 

N 

11 

Mission Allowance 

N 

12 

Annual Training Allowance 

N 

13 

Unit of Issue 

A2 

14 

CG Hazmat Class 

A4 

15 

MCC 

A1 

16 

Reroarks-Inv 

A30 

17 

DOT Hazmat Code 

A2 

18 

NHEEW 

N 

19 

Quantity on Hand 

N 


Figure 35. INVENTORY Detail Table for COMMAND 
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Restructuring Us_req table 


STRUCT=j 

-—Field Name 

fField Type^ 

1 

S-UIC 

A5 

2 

Document Number 

A14 

3 

Document Identifier 

A3 

4 

Reqn Class 

A1 

5 

Reqn Declas 

D 

6 

Remarks-Reqn 

A30 

7 

0-UIC 

A5 


Figure 36. REQUISITION Detail Table for COMMAND 
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Restructuring M_reqn table 



■ Field Name 

fField Type^ 

1 

Document Number 

A14* 

2 

Document Identifier 

A3 

:v 

Reqn Class 

A1 

4 

Reqn Declas 

D 

5 

Remarks-Reqn 

A30 


Figure 37. REQUISITION Object Materialization 







Figure 38, 
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Detail Tables for REQUISITION Master Table 
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Restructuring Req_adr table 


STRUCT 

1 




=Field Naine= 


Document Number 
Requisition Addressees 


Field 
A14 
A30 


Figure 39. Addressees Detail Table for REQUISITION 


Type. 
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Restructuring Req2_ln table 


STRUCT=j 

- -^Field Name -^— 

fField Types] 

1 

Document Number 

A14 

2 

NUN 

A9 

3 

Reqn Quantity 

N 

4 

Project Code 

A3 

5 

Media Status Code 

A1 

6 

Signal Code 

A1 

7 

Demand Code 

A1 

8 

Advice Code 

A2 

9 

Fund Code 

A2 

10 

Urgency of Need 

A1 

11 

Required Delivery Date 

A3 

12 

Status 

A1 

13 

Line Class 

A1 

14 

Priority 

A2 


Figure 40. LINE ITEM Detail Table for REQUISITION 
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Restructuring M_reqnxn table 

erpDTTr'T*—— 


biKUUl— 


1 

NUN 

2 

Reqn Quantity 

3 

Project Code 

4 

Media Status Code 

5 

Signal Code 

6 

Demand Code 

7 

Advice Code 

8 

Fund Code 

9 

Urgency of Need 

10 

Required Delivery Date 

11 

Status 

12 

Line Class 

13 

Priority 


Field Type 
A9* 

N 

A3 

A1 

A1 

A1 

A2 

A2 


A1 

A3 

A1 

A1 

A2 


Figure 41. LINE ITEM Tables 


141 





Restructuring M_s&lam table 


STRUCT^? 

-Field Name- 1 

rField Typeii 

1 

Serial Number 

A16* 

2 

Lot Number 

A16* 

3 

Maint. Due Date 

A3 

4 

Type of Maint. Due Code 

A1 

5 

Condition 

A1 

6 

Stowage Location 

A12 


Restructuring M_seram table 


STRUCT=j 

P-Field Name ■ 

fField Type^ 

1 

Serial Number 

A16* 

2 

Maint. Due Date 

A3 

3 

Type of Maint. Due Code 

A1 

4 

Condition 

A1 

5 

Stowage Location 

A12 


Figure 42. SF.RIAL & LOT and SERIAL AMMO Tables 
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APPENDIX J. PARADOX DATA VALIDITY CHECKS 

The following symbols are used in used in the PARADOX "Picture" data masks 
below; 

• # = Numeric digit 

• ? = Letter (A-Z or a-z) 

• & = Letter (convert to uppercase) 

• @ = Any character 

• ! = Any character (convert to uppercase) 

• ; = Take literally 

• * = Repetition counts (any length allowed by field type) 

• , = Alternative values 

As discussed in Chapter V, these data masks were adapted from the ARMIRS do¬ 
main definitions and use the symbols shown above: 

• Activity Classification Code: Default = A, Picture == A,B,D 

• Advice Code: Picture = #& 

• Annual Training Allowance: Picture = UMIrfr 

• ATR Class: Default = U, Picture = U,S 

• ATR Line Number: Picture = §§ 

• ATR Serial Number: Picture = ### 

• Balance Serviceable: Picture = ###'## 

• Balance Unserviceable: Picture = ##### 

• CG Hazmat Class: Picture = !!!! 

• COG Symbol: Picture = #& 

• Condition: Default = S, Picture = S,U 

• Condition Code; Default = A, Picture = A 

• Consignee/Consignor: Picture = #’#### 

• Demand Code: Default = R, Picture = N,R 

• Document Number: Picture = 

• Document Identifier: Picture = A01,A04,A0A,A0D 

• FAD: Min = 1, Max = 5, Picture = H 
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• Fleet: Picture = PAC, LANT 

• FSC: Picture = MM 

• Fund Code: Default = Y6, Picture = Y6, 26 

• Hull Number: &*! 

• Issue Code: Picture = !!!!!! 

• Julian Date: Max = 9366, Picture = ### 

• Line Class: Default = U, Picture = C,U 

• Location: Picture = &*? 

• Loss Code: Picture = LOSPI,LOSCE,LOSDE,LOSMD,LOSOT 

• Maint. Due Date: Picture = [#,&],## 

• MCC: Picture = & 

• Media Status Code: Picture = ! 

• Mission Allowance: Picture = ##### 

• Mission Area: Picture = ASW,ASUW,AAW,AM:W,MIW 

• NALC: Picture * !!!! 

• Name: Picture = .*! 

• NAR Serial: Picture = 

• NHEEW:*! 

• NIIN: Picture = *! 

• Old Balance: Picture = ##### 

• Priority: Min = 1, Max = 15, Picture = ## 

• Project Code: Picture = ### 

• Quantity Due In: Picture = ##### 

• Quantity Expended: Picture = jrMUU 

• Quantity Issued: Picture = ###'## 

• Quantity on Hand: Picture = 

• Quantity Received: Picture = ##### 

• Receipt Code: Picture = *! 

• Referenced ATR: Picture = ### 

• Reqn Class: Default = U, Picture = C,U 

• Reqn Quantity: Picture = ##### 

• Required Deliver}' Date: Min = 001, Max = 366, Picture = 
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Requisition Addressees: Picture = *! 

Revised Condition Code: Picture = & 

Serial Number: Picture = *! 

Service Code: Picture = ! 

Shipfill Allowance: Picture = ##### 

Short Title: Picture = *! 

Signal Code: Picture = & 

Sonobuoy Channel: Picture = §§ 

Status: Default = U, Picture = U,C,P,F 
Training Allowance Unexp.: Picture = 
Training Allow, to Charge: Picture = ##### 
Transaction Type: Picture = & 

Type of Maint. Due Code: Picture = & 

LTC: Picture = §§?§§ 

Unit of Issue: Picture = && 

Urgency of Need: Picture = A.BfC 
Warning Level: Picture = 









APPENDIX K. PARADOX REPORTS 
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Figure 47. Ammunition Inventory Report (Summarj) 
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APPENDIX L. ATR PREPARATION RULE BASE 


A. INPUT 

1. From ARMIRS Database 

• AMMO INVENTORY.NALC 

• COMMAXD.Fleet 

• COMMAXD.HulI Number 

• AMMUXITION.COG 

2. From User Responses To Queries 

a. Multiple Choice 

• CHOP 

• CHOP_From 

• CHOP_To 

• Deployed_To 

• Loaclout 

• Pre_Load 

• 60_Days_Berore 

• WiirDeploy 

b. Text for Addresses 

• Ex_Wep_Prep 

• In_Transaction 

• Squadron 

• Tender 

B. OUTPUT TO DATABASE 

• TRAXSACTION.ATR Class 

• TRANSACTIOX.ATR Declas 

• TRAXSACTIOX.Addrcssee (multi-valued) 
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C. USER DIALOG 

1. User Menu Selections 

1. MLSF Ships 

• IF COMMAND.Hull Number = A[*] 

• THEN 

• ASK MLSF: "Is this a Mobile Logistics Fleet ship?" 

• CHOICES MLSF: Yes, No 

2. Complete Onload,'Offload 

• ASK Loadout: "Was this transaction a complete ship onload or offload?" 

• CHOICES Loadout: Yes, No 

3. Current Deployment 

• ASK Deployed_To: "Where are you currently deployed?" 

• CHOICES Deployed_To: MED, WESTPAC, 6FLT, None of these. Not De¬ 
ployed Now 

4. Pre-Deployment Period 

• IF Deployed_To = Not Deployed Now 

• THEN 

• ASK 60_Days_Befoi'e: "Will your ship deploy within 60 days?" 

• CHOICES 60_Days_Before: Yes, No 

5. Pre-Deployement Loadout 

• IF 60_Days_Before = Yes 

• THEN 

• ASK Pre_Load: "Was this transaction a pre-deployment loadout?" 

• CHOICES Pre_Load: Yes, No 

6. Deployment Destination 

• IF 60_Days_Before = Yes 

• THEN 

• ASK Will_Deploy: "Where will you deploy ?" 

• CHOICES Will_Deploy: MED, WESTPAC, 6FLT, None of these 

7. Changing Operational Commanders (CHOP) 

• ASK CHOP: "Is this ATP>. a CHOP report?" 

• CHOICES CHOP: Yes, No 

8. CHOP Destination and Source 
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• IF CHOP = Yes 

• THEN 

• ASK CHOP_To: "What is your CHOP destination?" 

• CHOICES CHOP_To; LANT, PAC, EUR, Other 

• AND 

• ASK CHOP_From: "What is your CHOP source?" 

• CHOICES CHOP_From: LANT, PAC, EUR, Other 

2. User Text Entry 

1. Submarines 

• IF COMMAND.HuII Number = SSN[*] OR SSBN[*] 

• THEN 

• ASK Tender: "Type in the message address of your parent or operational sub¬ 
marine tender:" 

• CHOICES Tender: (user-entered text) 

2. Exercise Weapons 

• ASK Ex_Wep: "Does this transaction involve exercise weapons?" 

• CHOICES Ex_Wep: Yes, No 

• IFEx_Wep = Yes 

• THEN 

• ASK Ex_Wep_Prep:"Type in the message address of the activity preparing the 
exercise weapon:" 

• CHOICES Ex_Wep_Prep: (user entered text) 

3. Additional Standard ATR Addressees 

• ASK Squadron: "Type in the message address(es) of your parent/operational 
squadron commander:" 

• ASK In_Transaction: "Type in the the message address(es) of all other activities 
involvcdfin this transaction:" 

• CHOICES Squadron: (user entered text) 

• CHOICES In_Transaction: (user entered text) 

D. RULE BASE 

1. ATR Message Security Classification Rules 

{1 j Submarines 

• IF COMMAND.Hull Number = SSN(*] OR SSBN(*] 
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THEN 


• TRANSACT!ON.ATR Class = C AND TRANSACT!ON.ATR Declas= today 
+ 6 years 

• [THEN GOTO Addressing Rules] 

• BECAUSE: ATRs submitted by submarines (regardless of material reported) are 
classified Confidential and are declassified after six years. 

(2) Missiles, Rockets, and Torpedoes 

• IF AMMUNITION.COG = 8E OR 4E OR 4T OR 8T 

• THEN 

• TR.4NSACT10N.ATR Class = C AND TRANSACTION.ATR Declas = today 
+ 6 years 

• BECAUSE: ATRs pertaining to missiles or torpedoes are classified Confidential 
and are declassified after six years. 

{3) Sonobouys 

• IF AMMUNITION.COG = 8U 

• THEN 

• TRANSACTION.ATR Class = C AND TRANSACTION.ATR Declas = today 
+ 6 years 

• BECAUSE: ATRs pertaining to sonobuoys are classified Confidential and are de¬ 
classified after six years. 

(4) Complete Offloads and Onloads 

• IF Loadout = Yes 

• THEN 

• TRANSACTION.ATR Class = C AND TRANSACTION.ATR Declas = today 
+ 6 years 

• BECAUSE: ATRs pertaining to complete onloads,'offloads may contain informa¬ 
tion revealing onboard capabilities of major weapons systems. They are classified 
Confidential and declassified after six years. 

(5) Mines 

• IF AMMUNITION.COG = 6T 

• THEN 

• TR.-\NSACTI©N.ATR Class = C AND TRANSACTION.ATR Declas = today 
+ 30 years 

• BECAUSE: ATRs pertaining to mines, destructors, or mine components are clas¬ 
sified Confidential and are declassified after 30 years. 
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2. ATR Message Addressing Rules 

(1) COMINEWARCOMICOMOMA G 

• IFAMMUNITION.COG = 6T 

• THEN 

• [additional] TRANSACTION.Addressee = COMIKEWARCOM CHARLESTON 
SC and COMOMAG CHARLESTON SC 

• BECAUSE: All units reportinc mines, destructors, or mine components must info 
COMINEWARCOM and COMOMAG. 

(2) CINCLANTFLT 

• IF (CHOP_To = LANT) OR (CHOP_From = LANT) 

• THEN 

• [additional] TRANSACTION.Addressee = CINCLANTFLT NORFOLK VA 

• BEC.AUSE: All units reporting CHOP to or from the Atlantic Fleet must info 
CINCLANTFLT. 

{3y CINCPA CFLT; COMNA VLOOP AC 

• IF (COMMAND.Fleet = PAC) OR (CHOP To = PAC OR CHOP_From = 
PAC) 

• THEN 

• [additional] TRANSACTION.Addressee = CINCPACFLT PEARL HARBOR 
HI and COMNAVLOGPAC PEARL HARBOR HI 

• BECAUSE: All Pacific Fleet units and other units upon CHOP to or from the 
Pacific Fleet must info CINCPACFLT/COMNAVLOGPAC. 

(4) CINCUSNA VEUR 

• IF (COMMAND.Fleet = LANT AND Deployed_To = 6FLT) 

• OR (COMMAND.Fleet = LANT AND MLSF = Yes AND 60_Days Before = 
Yes AND \Vill_Dcploy = 6FLT) 

• OR(CHOP_To = EUR OR CHOP_From = EUR) 

• THEN 

• [additional] TRANSACTION.Addressee = CINCUSNAVEUR LONDON UK 

• BECAUSE: Atlantic Fleet units deployed to the Sixth Fleet, Atlantic Fleet MLSF 
ships within 60 days prior to such deployment, and all units reporting CHOP to 
or from the European area must info CINCUSNAVEUR. 

{5J COMNA VAIRLANT 

• IF (COMMAND.Fleet = LANT) AND (AMMUNTTION.COG = 8U) 

• THEN 
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• [additional] TRANSACTION.Addressee = COMNAVAIRIANT NORFOLK 
VA 

• BECAUSE: Atlantic Fleet units reporting sonobouys must info 
COMNAVAIRLANT. 

(6) COMNAVAIRPAC 

• IF(COMMAND.Fleet = PAC) AND (AMMUNTTION.COG = 8U) 

• THEN 

• [additional] TRANSACTION.Addressee = COMNAVAIRPAC SAN DIEGO CA 

• BECAUSE: Pacific Fleet units reporting sonobouys must info COMNAVAIRPAC. 

f?) Commander, Task Force 73 

• IF (COMMAND.Fleet = PAC) AND (Deploved_To = MED OR Deployed_To 
= WESTPAC 

• OR (COM.MAND.Fleet = PAC) AND ((MLSF = Yes) OR (COM.MAND.Hull 
Number = CV]’- ] OR CVN[’=']) AND (60_Days_Before = Yes)) 

• OR (COMMAND.Fleet = PAC) AND (Pre Load = Yes) AND 
(AMMUNITION.COG = 8E OR 4E OR 8T OR 4T 0"R 6T OR 8U) 

• THEN 

• [additional] TIU^NSACTION.Addressee = CTF SEVEN THREE 

• BECAUSE: Pacific Fleet units deployed to MED/WESTPAC and. Pacific Fleet 
MLSF and aircraft carriers within 60 days prior to deployment in addition to 
Pacific Fleet units reporting predeployment loadouts involving air launched mis¬ 
siles, surface launched missiles, torpedoes, mines, and sonobuoys must info CTF 
73. 

(8) Commander, Task Force 63 

• IF (COMMAND.Fleet = LANT) AND (Dcployed_To = MED) 

• OR (COMMAND.Fleet = LANT) AND ((MLSF = Yes) OR (COMMAND.Hull 
Number = CV[*] OR CVN[ •]) AND (60_Days_Before = Yes)) 

• OR (COMMAND.Fleet = LANT) AND (Pre_Load = Yes) AND 
(AMMUNTTION.COG = 8E OR 4E OR 8T OR 4T OR 6T OR 8U) 

• THEN 

• [additional] TR.ANSACTION.Addressee = CTF SIX THREE 

• BECAUSE: Atlantic Fleet units deployed to the MED and Atlantic Fleet .MLSF 
and aircraft carriers within 60 days prior to deployment in addition to Atlantic 
Fleet units reporting predeployment loadouts involving air launched missiles, sur¬ 
face launched missiles, torpedoes, mines, and sonobuoys must info CTF 63. 
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(9) COMFAIRWESTPAC 

• IF (COMMAND.Fleet = PAC) AND (AMMUNITION.COG = 4E OR 8E) 

• THEN 

• [additional] TRANSACTION.Addressee = COMFAIRWESTPAC ATSUGI JA 
and COMFAIRWESTPAC DET CUBI PT RP 

• BECAUSE: Pacific Fleet units reporting air launched missiles must info 
COMFAIRWESTPAC. 

(10) COMPACMISTESTCEN 

• IF (AMMUNITION.COG = 4E OR 8E) OR (AMMO INVENTORY.NALC = 
< Sea Sparrow> OR <Harpoon>) 

• THEN 

• [additional] TRANSACTION.Addressee = COMPACMISTESTCEN POINT 
MUGU CA 

• BECAUSE: All units reporting air launched missiles, Sea Sparrow, or Harpoon will 
info COMPACMISTENTCEN. 

(11) COMTHIRDFLV, COMNA VSURGR U MIDP A C 

• IF (COMMAND.Fleet = PAC) AND (In_Transaction = NAVMAG 
LUALUALEr HI) AND (AMMO INVENTORY.NALC = <5754 Pufr> OR 
<5738 Pufr>) 

• THEN 

• [additional] TRANSACTION.Addressee = COMTHIRDFLT AND 
COMNAVSURFGRU iMIDPAC 

• BECAUSE: Pacific Fleet units unloading or offloading 5754 or 5738 Puff rounds 
from.to Naval Masazine Lualualei, HI will info COMTHIRDFLT and 
COMNA VSURFGRU MIDPAC. 

112; JCMPO 

• IF AMMO INVENTORY.NALC = <Tomahawk> 

• THEN 

• [additonal] TRANSACTION.Addressees = JCMPO WASHINGTON DC 

• BECAUSE: All units reporting Tomahawk missile transactions will info JCMPO. 

(13) CMC WASHINGTON DC 

• IF AMMUNITION.COG = OT 

• THEN 

• [additional] TR.4NSACTION.Addressee = C.MC WASHINGTON DC 
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BECAUSE: All units reporting Marine Corps-controlled ammunition will info 
CMC. 


(14) NA VS HIP IVPNS YSENGS TA 
IF AMMUNITION.COG = 8E OR 8T 
THEN 

[additional] TRANSACTlON.Addressee = NAVSHIWPNSYSENGSTA PORT 
HUENEME CA 

BEC.AUSE: All units reporting surface launched missiles and certain air launched 
missiles will info NAVSHIPWPNSYSENGSTA. 

(15) PACMISTESTCEN DELANT 
IF(CO.MMAND.Fleet = LANT) AND (A.MMUNITIOX.COG = 8E) 

THEN 

[additional] TRANSACTlON.Addressee = PAC.MISTESTCENT DELANT 
YORKTOWN VA 

BECAUSE: Atlantic Fleet Units reporting certain air launched missiles will info 
PACMISTESTCEN DELANT. 

(16) Standard Information Addressees 

[additional] TRANS ACTION. Addressees = Tender AND Squadron AND 
InJ'ransaction AND Ex_Wep_Prep AND FLTAC CORONA CA 

BECAUSE: All units alwaysnnfo parent submarine tenders, squadron commanders, 
commands involved in the transaction, e.\ercise weapon preparation activity, and 
FLT.AC Corona, CA. 
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